From simple-bounces@ietf.org  Wed Dec  1 00:26:47 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02647;
	Wed, 1 Dec 2004 00:26:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZN68-0006e0-Fg; Wed, 01 Dec 2004 00:32:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZMz5-0002sl-AF; Wed, 01 Dec 2004 00:24:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CZMfz-00054G-DC
	for simple@megatron.ietf.org; Wed, 01 Dec 2004 00:05:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00479
	for <simple@ietf.org>; Wed, 1 Dec 2004 00:05:12 -0500 (EST)
Received: from [203.199.83.135] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZMl4-0006Be-36
	for simple@ietf.org; Wed, 01 Dec 2004 00:10:41 -0500
Received: (qmail 18529 invoked by uid 510); 1 Dec 2004 05:05:47 -0000
Date: 1 Dec 2004 05:05:47 -0000
Message-ID: <20041201050547.18528.qmail@webmail45.rediffmail.com>
Received: from unknown (203.126.136.223) by rediffmail.com via HTTP;
	01 dec 2004 05:05:47 -0000
MIME-Version: 1.0
From: "Anir  P" <anip_2010@rediffmail.com>
To: simple@ietf.org
X-Spam-Score: 4.0 (++++)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Subject: [Simple] hi
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Anir  P <anip_2010@rediffmail.com>
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="===============1087651016=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

 This is a multipart mime message


--===============1087651016==
Content-type: multipart/alternative;
	boundary="Next_1101877547---0-203.199.83.135-18524"

 This is a multipart mime message


--Next_1101877547---0-203.199.83.135-18524
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

 =A0=0AHi all=0ACan you please let me know to implement presence and instan=
t messaging shall we follow SIMPLE or shall we follow rfc 3861, 3862.=0A=0A=
Whats the industry trend..?=0A=0Aregards=0Aanip=0A
--Next_1101877547---0-203.199.83.135-18524
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0A&nbsp; <BR>=0AHi all<BR>=0ACan you please let me know to implement pr=
esence and instant messaging shall we follow SIMPLE or shall we follow rfc =
3861, 3862.<BR>=0A<BR>=0AWhats the industry trend..?<BR>=0A<BR>=0Aregards<B=
R>=0Aanip<BR>=0A=0A</P>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"http://cl=
ients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com=
/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=
=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1101877547---0-203.199.83.135-18524--



--===============1087651016==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1087651016==--




From mailman-bounces@ietf.org  Wed Dec  1 07:53:42 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24448
	for <simple-archive@ietf.org>; Wed, 1 Dec 2004 07:53:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZU4h-0007j9-Gs
	for simple-archive@ietf.org; Wed, 01 Dec 2004 07:59:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZSPA-0004My-5H
	for simple-archive@ietf.org; Wed, 01 Dec 2004 06:12:16 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@ietf.org
To: simple-archive@ietf.org
X-No-Archive: yes
Message-ID: <mailman.15808.1101897713.3553.mailman@lists.ietf.org>
Date: Wed, 01 Dec 2004 05:41:53 -0500
Precedence: bulk
X-BeenThere: mailman@lists.ietf.org
X-Mailman-Version: 2.1.5
List-Id: Mailman site list <mailman.lists.ietf.org>
X-List-Administrivia: yes
Sender: mailman-bounces@ietf.org
Errors-To: mailman-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, mailman-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

**********************************************************************

NOTE WELL:

Any submission to the IETF intended by the Contributor for publication
as all or part of an IETF Internet-Draft or RFC and any statement made
within the context of an IETF activity is considered an "IETF
Contribution". Such statements include oral statements in IETF
sessions, as well as written and electronic communications made at any
time or place, which are addressed to:

o the IETF plenary session, o any IETF working group or portion
thereof, o the IESG, or any member thereof on behalf of the IESG, o
the IAB or any member thereof on behalf of the IAB, o any IETF mailing
list, including the IETF list itself, any working group
  or design team list, or any other list functioning under IETF
auspices,
o the RFC Editor or the Internet-Drafts function

All IETF Contributions are subject to the rules of RFC 3667 and RFC
3668.

Statements made outside of an IETF session, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not IETF Contributions in the context
of this notice.

Please consult RFC 3667 for details.

*******************************************************************************


If you have questions, problems, comments, etc, send them to
mailman-owner@ietf.org.  Thanks!

Passwords for simple-archive@ietf.org:

List                                     Password // URL
----                                     --------  
simple@ietf.org                          onahda    
https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org


From simple-bounces@ietf.org  Wed Dec  1 13:27:49 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06451;
	Wed, 1 Dec 2004 13:27:49 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZZI4-0007Y3-1z; Wed, 01 Dec 2004 13:33:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZYEw-0001vJ-Dd; Wed, 01 Dec 2004 12:26:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXKI-0001Gd-F5
	for simple@megatron.ietf.org; Wed, 01 Dec 2004 11:27:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21321
	for <simple@ietf.org>; Wed, 1 Dec 2004 11:27:32 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZXPe-0003tG-29
	for simple@ietf.org; Wed, 01 Dec 2004 11:33:06 -0500
Received: from [192.168.1.216] (c-24-1-66-77.client.comcast.net [24.1.66.77])
	(authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB1GRJna032219
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 1 Dec 2004 10:27:22 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B044E56@rvil-mail.radvision.com>
References: <10DA2C035FE3BC4FA8D73EC55FC43D9B044E56@rvil-mail.radvision.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BB453B74-43B5-11D9-A8F0-000D93326732@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] Mistake in PRES-URI BNF
Date: Wed, 1 Dec 2004 10:26:19 -0600
To: "Tamar Barzuza" <TamarB@radvision.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit

Tamar -

I don't think that production was what anybody had in mind.
The intent was probably to = addr-spec.

We can put together a correction and figure out how to submit it.

Comments from anyone?

RjS

On Nov 29, 2004, at 5:51 AM, Tamar Barzuza wrote:

>> Hi,
>>
>> I found a problem in the BNF of PRES-URI.
>>
>> RFC 2396 defined the generic syntax of URI. It explicitly says that 
>> the following (delims) characters are disallowed within URI:
>> delims= "<" | ">" | "#" | "%" | <">
>>
>> However, in RFCs 3859 and 2822 the definition for PRES-URI is:
>> 	PRES URI = "pres:" [ to ] [ headers ]
>> 	to = mailbox
>> 	mailbox = name-addr / addr-spec
>> 	name-addr = [display-name] angle-addr
>> 	angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
>> 	addr-spec = local-part "@" domain
>> 	display-name = phrase
>> Which means that pres addresses can look like pres:"name"<user@host>, 
>> hence may contain " and <>.
>>
>> Therefore I believe that the PRES-URI BNF is mistaken.
>>
>> Thanks,
>> Tamar.
>>
>
> _______________________________________________
> 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 Dec  1 16:12:09 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24816;
	Wed, 1 Dec 2004 16:12:09 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZbr5-0004VW-UV; Wed, 01 Dec 2004 16:17:45 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZbTs-0004n5-EJ; Wed, 01 Dec 2004 15:53:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CZa3k-0007Hm-Nx
	for simple@megatron.ietf.org; Wed, 01 Dec 2004 14:22:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12600
	for <simple@ietf.org>; Wed, 1 Dec 2004 14:22:35 -0500 (EST)
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZa95-0000np-6H
	for simple@ietf.org; Wed, 01 Dec 2004 14:28:11 -0500
Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se
	[138.85.133.51])
	by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id iB1JMeCR029051;
	Wed, 1 Dec 2004 13:22:40 -0600 (CST)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service
	(5.5.2655.55) id <W9ZC0LGX>; Wed, 1 Dec 2004 13:21:10 -0600
Message-ID: <A1A09E7976B8754FA08AFDD3A969FD6A07834F32@lmc35.lmc.ericsson.se>
From: "Nancy Greene (QC/EMC)" <nancy.greene@ericsson.com>
To: "'Ben Campbell'" <ben@nostrum.com>
Subject: RE: [Simple] MSRP: need for 202 Accepted status code?
Date: Wed, 1 Dec 2004 13:19:44 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: "'ben@estacado.net'" <ben@estacado.net>, simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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="===============0434088302=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43

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.

--===============0434088302==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4D7DA.B6CEBD0C"

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_01C4D7DA.B6CEBD0C
Content-Type: text/plain;
	charset="iso-8859-1"

Friday, November 26, 2004 7:46 PM, Ben wrote:
<snip>

>We use 200 to mean success. The meaning of "success" for MSRP means the 
>message got to the device, and it will now try to do something with it. 
>The subtle distinction between 200 and 202 in SIP does not exist in 
>MSRP.

Ok, this is clearer now. In any case, when the message session is
established, the INVITE response would be 200 OK, and not 202 Accept.
Therefore it is hard to argue that an MSRP REPORT sent within that message
session should ever have 202 Accept.

And I don't think we want to allow a 202 Accept to an INVITE.

Nancy

------_=_NextPart_001_01C4D7DA.B6CEBD0C
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Simple] MSRP: need for 202 Accepted status code?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Friday, November 26, 2004 7:46 PM, Ben wrote:</FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt;We use 200 to mean success. The meaning of =
&quot;success&quot; for MSRP means the </FONT>
<BR><FONT SIZE=3D2>&gt;message got to the device, and it will now try =
to do something with it. </FONT>
<BR><FONT SIZE=3D2>&gt;The subtle distinction between 200 and 202 in =
SIP does not exist in </FONT>
<BR><FONT SIZE=3D2>&gt;MSRP.</FONT>
</P>

<P><FONT SIZE=3D2>Ok, this is clearer now. In any case, when the =
message session is established, the INVITE response would be 200 OK, =
and not 202 Accept. Therefore it is hard to argue that an MSRP REPORT =
sent within that message session should ever have 202 =
Accept.</FONT></P>

<P><FONT SIZE=3D2>And I don't think we want to allow a 202 Accept to an =
INVITE.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C4D7DA.B6CEBD0C--


--===============0434088302==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0434088302==--



From simple-bounces@ietf.org  Thu Dec  2 18:15:43 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12461;
	Thu, 2 Dec 2004 18:15:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ca0GK-00025G-DA; Thu, 02 Dec 2004 18:21:35 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZv3D-0001Xi-HD; Thu, 02 Dec 2004 12:47:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CZthB-0003hw-Lu
	for simple@megatron.ietf.org; Thu, 02 Dec 2004 11:20:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04776
	for <simple@ietf.org>; Thu, 2 Dec 2004 11:20:39 -0500 (EST)
Received: from voyager.coretrek.no ([212.33.142.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZtmj-00085X-RF
	for simple@ietf.org; Thu, 02 Dec 2004 11:26:26 -0500
Received: from localhost (localhost [127.0.0.1])
	by voyager.coretrek.no (Postfix) with ESMTP id 3478FA94CB
	for <simple@ietf.org>; Thu,  2 Dec 2004 17:19:56 +0100 (CET)
Received: from [192.168.1.67] (unknown [82.196.203.62])
	by voyager.coretrek.no (Postfix) with ESMTP id 59D70A9370
	for <simple@ietf.org>; Thu,  2 Dec 2004 17:19:55 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <FF2A02EC-447D-11D9-8E3D-000D93C60BA0@telio.no>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: simple@ietf.org
From: Hisham Khartabil <hisham.khartabil@telio.no>
Date: Thu, 2 Dec 2004 17:19:52 +0100
X-Mailer: Apple Mail (2.619)
X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Subject: [Simple] IPR Claims against SIMPLE WG 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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit

The first one is surprising. The second one is interesting (I'm one of 
the authors, but obviously not one of the inventors :). The third one 
is obsolete, I guess. The last one we all know about.

https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=494
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=330
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=235
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=422

Regards,
Hisham


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


From simple-bounces@ietf.org  Fri Dec  3 19:42:08 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24601;
	Fri, 3 Dec 2004 19:42:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaO5t-00021u-0P; Fri, 03 Dec 2004 19:48:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaNny-0004vn-An; Fri, 03 Dec 2004 19:29:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaNde-0001DA-LP
	for simple@megatron.ietf.org; Fri, 03 Dec 2004 19:19:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22927
	for <simple@ietf.org>; Fri, 3 Dec 2004 19:18:59 -0500 (EST)
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.33)
	id 1CaNjT-0001YO-II
	for simple@ietf.org; Fri, 03 Dec 2004 19:25:04 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-1.cisco.com with ESMTP; 03 Dec 2004 16:25:15 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB40IRAJ013596;
	Fri, 3 Dec 2004 16:18:28 -0800 (PST)
Received: from [10.242.2.111] (sjc-vpn2-239.cisco.com [10.21.112.239])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGC69336;
	Fri, 3 Dec 2004 16:18:27 -0800 (PST)
Message-ID: <41B10253.5080403@cisco.com>
Date: Fri, 03 Dec 2004 19:18:27 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anir P <anip_2010@rediffmail.com>
Subject: Re: [Simple] hi
References: <20041201050547.18528.qmail@webmail45.rediffmail.com>
In-Reply-To: <20041201050547.18528.qmail@webmail45.rediffmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit

These are not competitive works; the CPIM specs (including 3861 and 
3862) are used by SIMPLE.

-Jonathan R.

Anir P wrote:

>  
> Hi all
> Can you please let me know to implement presence and instant messaging 
> shall we follow SIMPLE or shall we follow rfc 3861, 3862.
> 
> Whats the industry trend..?
> 
> regards
> anip
> 
> 
> 
> <http://clients.rediff.com/signature/track_sig.asp>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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


From simple-bounces@ietf.org  Fri Dec  3 19:52:45 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25314;
	Fri, 3 Dec 2004 19:52:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaOGA-0002Dw-MF; Fri, 03 Dec 2004 19:58:50 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaNz1-0000ZA-SQ; Fri, 03 Dec 2004 19:41:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaNkT-0003eL-P7
	for simple@megatron.ietf.org; Fri, 03 Dec 2004 19:26:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23482
	for <simple@ietf.org>; Fri, 3 Dec 2004 19:26:02 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaNqI-0001hv-LX
	for simple@ietf.org; Fri, 03 Dec 2004 19:32:08 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-4.cisco.com with ESMTP; 03 Dec 2004 16:24:49 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB40PSD9017585;
	Fri, 3 Dec 2004 16:25:29 -0800 (PST)
Received: from [10.242.2.111] (sjc-vpn2-239.cisco.com [10.21.112.239])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGC69709;
	Fri, 3 Dec 2004 16:25:29 -0800 (PST)
Message-ID: <41B103F9.9090000@cisco.com>
Date: Fri, 03 Dec 2004 19:25:29 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] Mistake in PRES-URI BNF
References: <10DA2C035FE3BC4FA8D73EC55FC43D9B044E56@rvil-mail.radvision.com>
	<BB453B74-43B5-11D9-A8F0-000D93326732@nostrum.com>
In-Reply-To: <BB453B74-43B5-11D9-A8F0-000D93326732@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit

I agree this is definitely a mistake.

-Jonathan R.

Robert Sparks wrote:

> Tamar -
> 
> I don't think that production was what anybody had in mind.
> The intent was probably to = addr-spec.
> 
> We can put together a correction and figure out how to submit it.
> 
> Comments from anyone?
> 
> RjS
> 
> On Nov 29, 2004, at 5:51 AM, Tamar Barzuza wrote:
> 
>>> Hi,
>>>
>>> I found a problem in the BNF of PRES-URI.
>>>
>>> RFC 2396 defined the generic syntax of URI. It explicitly says that 
>>> the following (delims) characters are disallowed within URI:
>>> delims= "<" | ">" | "#" | "%" | <">
>>>
>>> However, in RFCs 3859 and 2822 the definition for PRES-URI is:
>>>     PRES URI = "pres:" [ to ] [ headers ]
>>>     to = mailbox
>>>     mailbox = name-addr / addr-spec
>>>     name-addr = [display-name] angle-addr
>>>     angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
>>>     addr-spec = local-part "@" domain
>>>     display-name = phrase
>>> Which means that pres addresses can look like pres:"name"<user@host>, 
>>> hence may contain " and <>.
>>>
>>> Therefore I believe that the PRES-URI BNF is mistaken.
>>>
>>> Thanks,
>>> Tamar.
>>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
> 
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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


From simple-bounces@ietf.org  Fri Dec  3 20:20:32 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27371;
	Fri, 3 Dec 2004 20:20:32 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaOh1-0002rd-Le; Fri, 03 Dec 2004 20:26:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaOPb-0000z8-SY; Fri, 03 Dec 2004 20:08:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaOAi-0004Qk-AA
	for simple@megatron.ietf.org; Fri, 03 Dec 2004 19:53:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25351
	for <simple@ietf.org>; Fri, 3 Dec 2004 19:53:09 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaOGY-0002Dr-4U
	for simple@ietf.org; Fri, 03 Dec 2004 19:59:14 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 03 Dec 2004 16:57:56 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB40qaIT018820;
	Fri, 3 Dec 2004 16:52:36 -0800 (PST)
Received: from [10.242.2.111] (sjc-vpn2-239.cisco.com [10.21.112.239])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGC71397;
	Fri, 3 Dec 2004 16:52:37 -0800 (PST)
Message-ID: <41B10A54.5060209@cisco.com>
Date: Fri, 03 Dec 2004 19:52:36 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: [Simple] Some thoughts on XCAP's resource architecture
References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>
In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Content-Transfer-Encoding: 7bit
Cc: HTTP working group <ietf-http-wg@w3.org>,
        "'simple@ietf.org'" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Content-Transfer-Encoding: 7bit

Thoughts inline.

Lisa Dusseault wrote:

> During the DC IETF, I expressed some reservations about XCAP to Ted and 
> Jonathan. Jonathan asked me to send a message to the SIMPLE list with my 
> comments, so here it is...
> 
> Based on the mailing list on the traffic, it appears that  XCAP is 
> supposed to be an extension or profile of HTTP, rather than just a 
> protocol that mimics the HTTP interaction style, and that as such it is 
> intended to be compatible with other extensions of HTTP.

It is not an extension, it is a usage or profile. That is, an xcap 
server is a compliant HTTP server. What we are doing is defining how to 
map HTTP URLS to a set of resources that constitute the components of an 
http document. The nature of those resources has an impact on how you 
might want to cache them and handle their etags, and that is described 
in xcap.


   I'm concerned
> that the current architecture of XCAP makes this difficult.  In 
> particular the XCAP resource ontology and the URL addressing style that 
> goes with it shifts the HTTP design along two major axes:
> 
> 1) Resource granularity
> 2) Dependency between resource
> 
> The first shift is in size and number of resources.  Because the path 
> part of the URL allows for XML node selection, there are many more 
> resources for a given volume of content material.  This affects us in a 
> number of ways.
> 
> 1a) HTTP intermediaries and scaling: caches aren't designed to cache 
> huge numbers of tiny resources.  It would probably be wise to disable 
> caching on XCAP responses.

This is described in section 9 of xcap, which more or less says that you 
will want to disable caching for dynamic resources - ones frequently 
written by clients or otherwise. However, there are application usages 
where the data is primarily read-only. In that case, its reasonable to 
allow caching of those resources.

As such, there is an interaction with xcap and caching, but not because 
the resources are small - because they may be dynamic. This is an issue 
for any http resource.

> 
> 1b) HTTP servers aren't designed for that many small resources.  There's 
> a certain amount of overhead to maintaining the metadata (at a minimum, 
> the ETag) for so many small resources.  An HTTP server might have to be 
> rearchitected to do a scalable job of supporting XCAP, which increases 
> the XCAP implementation costs in the long run.

This is a possibly an implementation issue, certainly not a protocol 
one. As Joe pointed out in this thread, http itself says nothing of the 
typical size of resources, and lots of them are these tiny little 
things. In any case, I might expect xcap implementations to use database 
backing stores, but its an implementation choice and ymmv.

> 
> 1c) Performance: HTTP is designed to batch requests in a certain way 
> based on the granularity assumptions.  Recall that latency is a much 
> bigger problem than bandwidth above a certain (low) bandwidth, and in 
> modern Internet applications it's usually the latency that kills you.  A 
> more granular approach to resources doesn't in itself kill performance 
> but it does if you stay with HTTP's request granularity.  What XCAP is 
> saving in bandwidth it will lose, in many use cases, in latency costs.

I don't follow here. If you want to pipeline requests where you don't 
require conditional puts, go ahead and do so.

> 
> 1d) Extensions to HTTP have also been designed with HTTP's current 
> granularity in mind.  RFC2518, RFC3253, RFC3229, RFC3744 all extend HTTP 
> in useful ways, and they're all written with the assumption that the 
> granularity of resources is pretty much what it is today.  Access 
> control, in particular, has a lot of overhead per resource

Again, I don't think http itself says anything about what the 
granularity of a resource is supposed to be.

> 
> 2)  Dependencies:  HTTP servers are designed such that static resources 
> are handled independently of each other. Their ETag management is 
> stand-alone, the request and response handling and concurrency are 
> designed for that independence.  By contrast, XCAP contemplates a large 
> number of resources which really map to parts of the same underlying 
> file.  As far as I can tell, that introduces dependencies between 
> resources (for example that a PUT to one URL would require the ETag of 
> another URL to change).

Yes, xcap does introduce interdependencies between resources. AFAIK, 
there is nothing in http that says this is disallowed. Indeed, one can 
very well imagine that, in many cases, a change in one resource - 
affected through http directly or through back end applications, will 
affect other resources too.

> 
> 2a) HTTP implementation barriers.  The last HTTP server I developed 
> would have to be rearchitected in several places to handle XCAP's 
> interdependencies, work beyond what you'd expect from adding XCAP 
> support.  Throughout the server, the code uses exact matching of URLs to 
> figure out what to do -- not URL pattern matching. So for example:
>  - The way ETags were generated and stored and changed would have to be 
> thrown out because ETags were generated independently for every resource.
>  - Since resources were independent, write requests for different 
> resources could be handled concurrently with ease, but that would have 
> to change.

The proof is in the implementations; we have a few already, and those 
folks have posted here that they havent seen these problems.

> 
> 2b) How interdependencies work within existing HTTP extensions: For one, 
> somebody would have to write a specification for how the existing access 
> control standard (RFC 3744) might work with XCAP.  Since XCAP can have 
> two different URLs that point to the same underlying piece of data, what 
> does it mean to apply certain access control settings to either or both 
> of those URLs?

Its a good question, but not one new to this application. Certainly 
other http applications may require a client to obtain multiple locks in 
order to make a change across several resources that they require to 
affect. Same would be true here.

> 
> I haven't examined every feature of HTTP and its extensions to see how 
> well it deals with interdependencies, but that's a sampling.
> 
> So, what to do? It doesn't seem to me that XCAP is going to go back to 
> the drawing board (or needs to), but it would be sufficient for most of 
> the above concerns to simply make the definition of "resource" stay with 
> the root XML documents that XCAP deals with.  The existing extensions to 
> HTTP work a lot better on that size resource.  Part of this change 
> involves putting the XPATH-like part of the XCAP URL out of the path 
> part of the URL.  It could go in a header or even in the URL after the 
> query delimiter (the question mark).  There is a theoretical problem 
> with using query parameters on HTTP URLs in PUT requests if 
> write-through caches don't know how to handle those, but there aren't a 
> lot of write-through caches and overall it's a smaller problem and less 
> work to deal with.

I think that the PUT issue is a small detail, but there is a much more 
fundamental problem with what you are proposing.

The whole idea of xcap is that you can PUT a section of the xml document 
to the server, and that this made sense because the resource you were 
PUTting to *was* section of the xml document you want to affect. The URL 
referred to that resource. Thus, it is fundamental that the resources 
that we are manipulating are the various pieces of the overarching xml 
document. Your complaint is not that we are using a query string instead 
of a path separator, but that the *resource* is the document 
sub-components instead of the document itself. As such, changing xcap so 
that the only resource is the document is a fundamental architectural 
change. The fact that a PUT with query parameters might not work is 
symptomatic of the problem with this approach, and I suspect there are 
others.

Jamie Lokier wrote:
> Lisa Dusseault wrote:
> 
>>> If you have multiple changes to make to a 1 MB or smaller document, 
>>> batch them up together if possible, even if it requires uploading the 
>>> whole document afresh.  The current design of XCAP encourages changes 
>>> to be made independently, and each change will require a full 
>>> round-trip (no pipelining possible because you need to wait for the 
>>> server to respond with an ETag each time).
> 
> 
> That seems like a flaw which should be fixed.

I have to disagree with Lisa here, this is not a constraint on xcap. You 
do not have to wait for the etag to send the next request. You only have 
to wait for the etag if you wish your next change to be conditioned on 
the fact that the document hasn't been modified since your last change. 
That's true of http generally, and true here too - its the defining 
purpose of the If-* headers. The various application usages talk about 
ways in whcih the documents are structured so that one doesn't need to 
used conditional PUts'. In that case, feel free to pipeline.

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  Fri Dec  3 20:23:49 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27572;
	Fri, 3 Dec 2004 20:23:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaOkB-0002vm-Pa; Fri, 03 Dec 2004 20:29:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaOPq-0001UY-Di; Fri, 03 Dec 2004 20:08:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaOMQ-0007jT-9P
	for simple@megatron.ietf.org; Fri, 03 Dec 2004 20:05:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26233
	for <simple@ietf.org>; Fri, 3 Dec 2004 20:05:16 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaOSF-0002VT-NI
	for simple@ietf.org; Fri, 03 Dec 2004 20:11:20 -0500
Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB4134mK098178
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 3 Dec 2004 19:03:05 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Date: Fri, 3 Dec 2004 19:03:04 -0600
To: Hisham Khartabil <hisham.khartabil@telio.no>, Robert Sparks <RjS@xten.com>,
        Rohan Mahy <rohan@ekabal.com>, Cullen Jennings <fluffy@cisco.com>,
        Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>
Subject: [Simple] MSRP: sdp usage compared to BFCP
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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit

In the DC meeting, Gonzalo asked us to compare how MSRP and BFCP use 
SDP. Since they are both connection oriented, this seems to be a 
sensible thing to do. So, I took a shot at it;

1) BFCP depends on COMEDIA. MSRP does not.

The reason MSRP does not invoke COMEDIA is mainly a historic one. At 
the time we wrote that part of the spec, COMEDIA had not progressed as 
far as it has now. Instead, MSRP states a default connection 
"direction", and says that other mechanisms can be used to determine 
direction once they become standardized.

2) MSRP uses a URL in an a-line attribute to determine where to connect 
(address, port, protocol). I _think_ BFCP uses the traditional 
mechanism of an address in the c-line and a port in the m-line. This is 
not entirely clear to me, as the BFCP SDP draft says in one paragraph 
that the port is always ignored, and in another paragraph that the 
m-line port is the port too which a client connects. I gather the point 
is to say that the m-line port is only meaningful to the peer that 
opens the TCP connection. Along the same line, BFCP uses the m-line 
format field to determine whether to invoke TLS, while MSRP uses the 
URL in the path attribute.

The main reason is that MSRP uses URLs in the path attribute is, it 
must be able to communicate a path of URLs, rather than a single URL.  
That does not appear to be an issue with BFCP. There has been some 
recent controversy the MSRP usage. I will send a summary of that in a 
separate email.

3) Both MSRP and BFCP use a "*" in the m-line fmt-list field. But I 
think this is for different reasons. MSRP does this because it uses 
a-line attributes to determine the acceptable formats. I gather BFCP 
does this because content-type negotiation is not relevant to it.

It seems to me that each of these differences are due to semantic 
differences between the two protocols. That is, they are appropriately 
different.

I welcome any discussion, both on whether I interpreted the BFCP SDP 
usage correctly, and whether the differences are really appropriate.

Thanks!

Ben.


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


From simple-bounces@ietf.org  Sat Dec  4 02:01:07 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20203;
	Sat, 4 Dec 2004 02:01:06 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaU0f-00016o-Oz; Sat, 04 Dec 2004 02:07:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaTkS-0000at-Bw; Sat, 04 Dec 2004 01:50:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaTaI-0005vA-Bw
	for simple@megatron.ietf.org; Sat, 04 Dec 2004 01:39:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17683
	for <simple@ietf.org>; Sat, 4 Dec 2004 01:39:57 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaTgA-0000f6-LN
	for simple@ietf.org; Sat, 04 Dec 2004 01:46:03 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 03 Dec 2004 23:47:15 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB46dLD9019528;
	Fri, 3 Dec 2004 22:39:23 -0800 (PST)
Received: from [192.168.1.102] (che-vpn-cluster-2-5.cisco.com [10.86.242.5])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGC78368;
	Fri, 3 Dec 2004 22:39:20 -0800 (PST)
Message-ID: <41B12B9F.6000608@cisco.com>
Date: Fri, 03 Dec 2004 22:14:39 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Subject: Re: [Simple] Some thoughts on XCAP's resource architecture
References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>	<20041128012722.GA49273%ginga@ginganet.org>
	<41A9B79A.9020904@gmx.de>
In-Reply-To: <41A9B79A.9020904@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.7 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: "'simple@ietf.org'" <simple@ietf.org>, KAWAGUTI Ginga <g.kawaguti@ntt.com>,
        Lisa Dusseault <lisa@osafoundation.org>,
        HTTP working group <ietf-http-wg@w3.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
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit



Julian Reschke wrote:
> KAWAGUTI Ginga wrote:
> 
>> ...
>> XCAP's target document is usually written in UTF-8(it's XML),
> 
> 
> Unless XCAP says something normative, it could be any encoding. As far 
> as I can tell, the actual decoding doesn't matter at all as long as it 
> is one of the XML required ones (thus UTF-8 or UTF-16).
> 
>> so XCAP requires Xpath stuff(utf-8) into URL part, which is usually
>> considered as US-ASCII.
>> There are ways to encode utf-8 string into URL part, but
>> I don't think there's any unique, robust and common way for doing it.
> 
> 
> No matter what encoding the document uses, XCAP needs to define that 
> mapping (and yes, that mapping needs to be based on UTF-8).

This is a good point; I've gotten a private comment about this as well. 
I think the simplest thing is to normatively state that all XML 
documents managed by XCAP have to be utf-8 encoded. In terms of a 
mapping from UTF-8 strings into a URI, can you clarify why this is hard? 
Isn't it just a matter of escape-coding the octet sequence associated 
with non-ascii characters (I admit this is not my area of expertise and 
I likely am missing something here).


-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  Sun Dec  5 21:21:47 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29253;
	Sun, 5 Dec 2004 21:21:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cb8bp-0005Ru-Qz; Sun, 05 Dec 2004 21:28:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cb8PC-0001UF-Vj; Sun, 05 Dec 2004 21:15:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb8IF-0000eK-8U
	for simple@megatron.ietf.org; Sun, 05 Dec 2004 21:08:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28489
	for <simple@ietf.org>; Sun, 5 Dec 2004 21:08:01 -0500 (EST)
Received: from mgw2.noc.ntt.com ([210.163.32.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb8OU-0005Dr-Iz
	for simple@ietf.org; Sun, 05 Dec 2004 21:14:32 -0500
Received: from mop2.noc.ntt.com
	by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id iB627BYh016974;
	Mon, 6 Dec 2004 11:07:11 +0900 (JST)
Received: from mip3.noc.ntt.com (mvi2.noc.ntt.com)
	by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id
	<0I8A00CXC37ZHI@ntt.com>; Mon, 06 Dec 2004 11:07:11 +0900 (JST)
Content-return: prohibited
Date: Mon, 06 Dec 2004 11:07:11 +0900
From: "Kawaguti Ginga" <g.kawaguti@ntt.com>
Subject: Re: [Simple] Some thoughts on XCAP's resource architecture
In-reply-to: <41B18709.1040502@gmx.de>
To: "Julian Reschke" <julian.reschke@gmx.de>
Message-id: <20041206020711.GO3856@ntt.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
User-Agent: Mutt/1.5.4i-ja.1
References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>
	<20041128012722.GA49273%ginga@ginganet.org> <41A9B79A.9020904@gmx.de>
	<41B12B9F.6000608@cisco.com> <41B18709.1040502@gmx.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: "'simple@ietf.org'" <simple@ietf.org>, KAWAGUTI Ginga <g.kawaguti@ntt.com>,
        Lisa Dusseault <lisa@osafoundation.org>,
        HTTP working group <ietf-http-wg@w3.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

In Sat, Dec 04, 2004 at 10:44:41AM +0100,
Julian Reschke <julian.reschke@gmx.de> wrote:
> >This is a good point; I've gotten a private comment about this as well. 
> >I think the simplest thing is to normatively state that all XML 
> >documents managed by XCAP have to be utf-8 encoded. In terms of a 
> 
> That may be a bad choice if lots of your data is in characters that need 
> multi-byte sequences, in which case UTF-16 may be more efficient. I 
> think XCAP should simply stick with what XML requires (which is UTF-8 
> and UTF-16, nothing more).

I agree that "hard-assumption of UTF-8 usage" is a bad choice.
UTF-8 is only a DEFAULT encoding for XML standard.
Yes it is recommended to use UTF-8, but there are many other XML documents
based on other encodings (not only UTF-16, but many more).

If XCAP is intended to be very specific protocol only for
some limited XML documents, then "all documents are UTF-8(and/or UTF-16)" 
assumption might work, but it's a bad idea for general protocol design.

There are many ways to specify encodings in a XCAP-only-way,
like appending "http://.../...?encoding=utf-8?...",
but they're not HTTP-standard way.


And something more, URL string size limitation.
"% encoded" UTF-8 string might suffer even more on this restriction.


Julian's previous mail:
> > If that argument was in body part(header might also be recepted),
> > this consideration is much less problem, because there are ways to
> > declare encodings, and usual gateways/clients are aware of them.
> 
> Don't understand. How are you sending the document selector inside the 
> request body for PUT?

For generic HTTP PUT, there's no way, as denoted in your comment.
My consideration was to use something like SOAP envelope.
It shouldn't be "PUT" anymore, and it should be used over
some original rule anyway.

Regards,
Ginga Kawaguti

-- 
Office:  NTT Communications Innovative IP Architecture Center 1PT 1P
Address: KAWAGUTI Ginga <g.kawaguti@ntt.com>
Phone:   voice=+81-3-6800-3032; fax=+81-3-5388-0550

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


From simple-bounces@ietf.org  Mon Dec  6 09:39:12 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17598;
	Mon, 6 Dec 2004 09:39:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbK7Z-0006To-24; Mon, 06 Dec 2004 09:45:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbJxc-0000qY-1K; Mon, 06 Dec 2004 09:35:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbJwY-0000VF-Fk
	for simple@megatron.ietf.org; Mon, 06 Dec 2004 09:34:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17364
	for <simple@ietf.org>; Mon, 6 Dec 2004 09:34:24 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbK2u-0006Or-8i
	for simple@ietf.org; Mon, 06 Dec 2004 09:41:01 -0500
Received: from [192.168.1.216] (c-24-1-66-77.client.comcast.net [24.1.66.77])
	(authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB6EYKhC052860
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <simple@ietf.org>; Mon, 6 Dec 2004 08:34:20 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <EB441A08-4793-11D9-8F23-000D93326732@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: simple@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Date: Mon, 6 Dec 2004 08:34:21 -0600
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2
Content-Transfer-Encoding: 7bit
Subject: [Simple] Draft minutes - SIMPLE - IETF61
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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5
Content-Transfer-Encoding: 7bit

Please review - send any corrections to the list by this Thursday 12/9.

Thanks,
RjS
-----------------------------------

Minutes - IETF61 - SIMPLE WG meeting - Washington, D.C.
(SIP for Instant Messaging and Presence Leveraging Extensions)

Summary:

MSRP:
   Several changes were made in response to Sam Hartman's
   security review. The group is comfortable with those changes.
   The number of open issues is rapidly decreasing - we expect
   these drafts to be last-called after thier next revision.
   The chairs will obtain appropriate review of the drafts use
   of SDP.

Presence Rules:
   The group extensively discussed what it means to allow rules
   based on anonymous or unauthenticated identities. No specific
   decisions were made during this discussion.

Partial PIDF:
   The group noted the similarity between the differencing
   mechanisms in this draft and the mechanisms in XCAP. There
   was consensus to work towards a common mechanism.

Partial publish/notify:
   Draft will be clarified with guidelines on when to use the
   partial mechanisms.

XCAP:
   The group rejected a proposal to allow idempotency tests
   other than GET(PUT(X))==X. Jonathan will make minor revision
   to the core draft which will then be ready to submit for
   publication.

Presence Data Model:
   The group reached consensus that the model must provide a
   way to pass potentially conflicting information through a
   compositor without losing data.
   The group concluded that the  algorithms for applying
   composition and selecting policy rules will be different.
   There was extensive but inconclusive discussion around
   differentiating services (tuples) based on URI equivalency.

Raw notes from each session follow:

-----------------------------------------------------------

Notes, SIMPLE First Session, IETF61
Reported by Dean Willis

Agenda bashed.

Status of various drafts presented on slides. Noted that "is
composing" is in RFCED queue, not IESG queue.

Topic: MSRP
------------------------------------------------------------
Discussion lead by Ben Campbell
Slides presented.

Changes since last pub and dependencies reviewed.

Changes from security review:

Added applicability statement around usage with rendezvous/negotiation
protocols.

Mapping of "im:" URIs. This needs to be in  a separate
document. Dicussion ensued as to whether MSRP blocks on this
document. The general consensus is that it does not, as MSRP never
sees an "im:" URL (this would be a rendezvous dependency).

Security review suggested reintegrating core and relay
drafts. Consensus seems to be to resist that suggestion. Suggested
that the full security story needs to be in one of the two drafts.

Previous deaft missed RFC 3682 Application Considerations on usage of
CPIM headers. This has been clarified.

Open issues:

"?" Parameter Syntax: Proposed that this be added to the next
rev. Discussion: Cullen has a concern that this may break the security
model and will review offline with author to ascertain.

Overlapping Chunks: Concluded to recommend that most recently received
chunk wins unless the application domain dictates otherwise.  No
arguments raised against proposal.

Report handling: Consensus among authors that current draft is
underspecified. Proposed that negative reports be "per chunk" and new
incremental values for Report-Success (as well as per-message) be
permitted. No argument raised against proposal. Further: Relaible
delivery requires positive Report-Success or incremental,
Report-Failure allows rapid failure detection (along with normal
failure timeouts). This would require requesting both success and
failure reports at session setup. No argument against
proposal. Further: Proposed that spurious reports be silently
dropped. No arguments araised against proposal.

Discussion: Does Section 8 (O/A, SDP Ext.) need to be reviewed
elsewhere? This includes some a-line attributes and fmt, and that
sdp-new requires a more detailed registration process. We may also
need to register TCP as a transport. Task: Chairs will work it out
with other chairs and ADs. Note: TCP has been registered as part of
comedia.

Discussion: Have there been any implementations? One report of
preliminary implementation experience, on which the developers had
"serious heartburn", primarily around the abnf that was supposedly
fixed in this release. One other concern was raised around handling
the closing -- given the structure, one can't detect flow end strictly
by ABNF, and list consensus was to stay with this.

Discussion: Is the flow control built into MSRP justifiable? If so,
then we need a relay push-back capability to handle
buffer-overflows. This interacts with "many-flows onto one-TCP"
plexing, and providing reordering of chunks. Argued that reordering is
required anyhow, so this is no added complexity. Conclusion is that
the current text seems consistent with our understanding of
requirements.

Discussion: Similar SDP-ish stuff is being described in BFSCP. Should
we unify? Concluded that the authors will get together and discuss.

Further discussion on implementation: Implementors seem to be
deferring deployment until the RFC is published. This view is
supported from experience reported in 3GPP about their attempt to use
MSRP.


Topic: MSRP Relay
--------------------------------------------------
Discussion led by Cullen Jennings
Slides Presented

Noted that we need one example in text. Other than that, there have
been no comments on-list.

Poll: Who is planning to implement MSRP base? (Many, app. 40). Who is
planning to implement MSRP relay (much smaller, app. 9).

Poll: Who plans to read and comment during last call (very many, 1/3
of room).



Topc: Presence Rules
---------------------------------------------------
Discussion led by Jonathan Rosenberg
Slides presented.

Slides review changes from previous version.

Discussion of anoymous: Seems to be a desire to differentiate an
"unknown user" from a "user authenticated to the network who prefers
not to disclose". Is a non-authenticated "From" identity not the same
as anonymous? How does this relate to Caller IDs "Anonymous" vs
"Unavailable"? Is there a need to present anything relative to the
strength of authentication used? Proposed: no plan to add an
"authenticated" condition. Unauthenticated identities will be
considered comparable to "unknown". Local policy will determine
whether any specific authentication technique counts as
"authenticated", and techniques below this threshold would be counted
as "unknown".

Proposed that we may need a way to match "any" identity in a rule.

More discussion.

New proposal: Delete special treatment "for authenticated but
anonymous" and consider all non-revealing identities "unknown".

More discussion.

Point: Unauthenticated should NEVER receive more information than
"authenticated but anonymous".

Editor: Why does nobody seem to understand that this is a two-axis
system?  Axis 1 is "Authenticated vs. Unauthenticated", and axis 2 is
"Presenting vs Not Presenting Identity", and that decisions need to be
made for at least three of the four resulting tuples?

No conclusion noted.

Changes since last rev reviewed.

Several issues drew brief discussion with some suggestions of
discussing offline.

Discsussion returned to identity, the uncertain, and the unknown. The
result was unclear.

-----------------------------------------------------------------------
(Note that we were fortunate enough to have two notetakers for
  the second session. Both sets of notes appear here)
-----------------------------------------------------------------------

Notes, SIMPLE session two, IETF 61
Reported by Ben Campbell

------------------Partial PIDF format 02 (Jari Urpalainen)

--"patch" model for pidf docs.

add, remove, replace, but no creation.
failure falls back to unchanged pidf doc.

question: similar to xcap operations--how close is the relationship?
answer: very close--same operations that any xml database uses.

issue: this is a compression scheme on xml docs, based on diff. We 
should have one way for all xml docs, not one for each. similar to xcap

Further discussion about competing with xcap, and which is more simple 
and/or compact.

Issue: Is this just xcap with different attribute names?

Jonathan agrees to look at possible improvements to xcap.

Chair: Both this and xcap took divergent evolutionary paths to a 
similar place--no competition intended. Need to talk to other groups 
working on xml diff formats.

--------------Partial Presence (Aki)
*-partial-publish-01
*-partial-notify-03

Radical simplification
No longer tuple specific.

Issues: What if updated version is garbage?

Issue: Do we need guidlines to avoid sending partial pidf that is 
bigger than whole doc. Don't want to do a large number of small 
changes.

Resolution: We think it is already addressed in draft. (Maybe just 
notification, but needs to be in publish.)

---------------------------XCAP Needed diffs (Jonathan)

Issue: xcap equates get(put(x))==x as idempotency. This is sufficient 
but not necessary. ( if-match requests are all idempotent)

Options: Clarify, but keep normative text; allow other idempotent ops.
Proposal:Keep normative text.

discussion: does get(put(x))==x also check for concurrent changes?

Resolution: accept proposal.

Issue: xcap list usage talks about unioning liest elements. But 
operation is more complex--ns prefix can get lost. (see slide for 
accuracy)

Proposal: when <service> element copied into global doc, add a 
namespace prefix def for all in-scope ns. If default differes from 
global def, add a new default.

Resolution: accept proposal.

chair: draft already last called, need to post changes on list.

----------------------------Presence Data Model Open Issues (Jonathan)

Topic: One element vs many. Currently only one person element. Only one 
definition for any one device or service.

question: do we allow multiples? Represents unresolvable conflicting 
info at compositor.

Jonathan and Henning present arguments for each side.

Comment: Need ability to be lossless.
Comment: Both models may be needed.
Comment: No _practical_ one best composition policy.
Comment: Need something deterministic to publisher and watcher.
Comment: Even an endpoint can publish conflicting information.
Comment: Can we have a way to show a "preferred" view of data for dumb 
consumers, but also show raw or conflicting data for smart consumers? 
This requires some form of metadata.
comment: want to do something today that allows complex solutions in 
the future, but not necessarily solve all the hard problems now.

Resolution: Need the ability to avoid loss and express conflicting 
data. This will come with some complexities. Will not try to specify 
all complexity up front, but want to specify some method of specifying 
a "preferred" instance out of a conflicting set.

Topic: Spheres- for variables that serve as rule selectors (e.g. 
sphere) into privacy policy, need to determine which is used. 
Composition output and rule selection are logically distinct.

Proposal: Allow separate algorithms for rule selection and composition. 
Selection algorithm could be local policy, or a standardized algorithm.

comment: composition could include conflicting spheres.
Comment: we need to discuss atomicity of conflicting info.
comment: determining sphere priority is policy decision.
comment: May need to select included in composed document.

Resolution:

1) Composition and selection algorithms are separate.
2) Selection algorithm is application defined for now, but we may need 
to define a default in the future.

Topic: Multiple services with same URI

Do we need different identifier, but with same contact ID. What if pua 
publishes multiple serices with Contact containing AoR?

How do you identify conflicting services vs just different services?

How about different services at same device with same URI? Example of 
one softphone doing voice and IM, currently available for IM but not 
voice.

Discussion about whether this is a capabilities problem or something 
else.

We appear to have very different views of what service means, before we 
can determine encoding.

Call attention to henning point: Differentiating tuples based on URI 
equiv. Do compositors group things into multiples based on URIs. But 
can compositors cannot canonically compare all URIs.

Attempt to call question:
1) What is interpretation of two tuples with same contact URI
2) Should we force a composer to remove and compose multiple tuples 
with the same URI if it can tell?

Resolution: None--take it to the list.

-----------------------------------------------------------------------
(Note that we were fortunate enough to have two notetakers for
  the second session. Both sets of notes appear here)
-----------------------------------------------------------------------

Notes, SIMPLE Second Session, IETF 61
Reported by Dean Willis


Topic: PIDF Partials
----------------------------------------------------
Discussion led by  by Jari Urpalainen
Slides presented

Comment: There would be a benefit to having some sort of XML
compression and partial scheme that would work across
applications. Discussion followed on this approach vs xcap
diff. Author maintains this approach is shorter and should replace
xcap diff. Suggested that there should be comparisons made with real
messages.

Comment: It appears that the net effect is that we have different XML
element names.

The previous proposal worked on the element level, whereas this
approach is doing more of a syntactic patch.

Consensus: We should settle on one technique -- this or XCAP diff, or
whatever. Noted that XCAP diff is already a WG document, so we should
study this approach and see what, if any, makes it better, then add
that to xcap diff.

Chair commentary: This is the result of convergent evolution, and we
should take this to the list for convergence. We do still have a need
for partial notification. We should also check with people outside
SIMPLE who are doing XML diffs.


Topic: Partial Presence
------------------------------------------------------
Discussion led by Aki Niemi
Slides presented.

Goal: A small change in presence should produce a small NOTIFY.

Noted that this technique should work for any event package using XML
bodies.

Observed that sometimes, for a very small document, a partial update
might be larger than a full update due to the extra syntax. It was
discussed as to whether the draft has adequate guidance on "when" to
use the partial format.


Topic: XCAP Needed Diffs
-------------------------------------------------------
Discussion led by Jonathan Rosenberg
Slides presented.

Issue: Noted that draft needs to clarify usage of term "idempotency".
Discussion of this term and usage followed.

Issue: Namespace prefix definitions. Fix proposed in
slides. Discussion: Could this lead to a collision? Ans. No, the
prefix definition is at the service element itself.

Conclusion: Author will submit a revised draft.


Presence Data Model Open Issues
--------------------------------------------------------
Discussion led by Jonathan Rosenberg and Henning Schulzrinne
Slides presented.

Issue: One element vs. many. Current system does not allow conflicting
data. It has been proposed tha twe allow multiple service elements,
representing conflicting input to the compositor, allowing the watcher
to decide.

Proposal: Stay with existing system (argued by JDR). This generates
issues for automata as consumers of services. This may also lead to
multiple ways of interpreting conflicting data vs. simultaneous
capabilities, and could be problemactic. This also requires adding a
tuple/element identifier, and may need lots of additional metadata to
make the interpretation feasible. Alternate approach would be to add a
"<conflict>" wrapper later.

Proposal: Add support for many elements (Argued by HGS). Most existing
presence systems have only once source of presence data. They don't
need to do multiple elements. However, we are now building multisource
systems, and need multiple elements to meet additional requirements
listed in slides.

Noted that one could add a "<view>" or "<conflict>" wrapper now, to
accomplish something similar, but that if it is added "in the future",
we will have a major backward compatibility problem.

Disussion follows . . .

Observed that conflicting data will occur -- the Question is how to 
deal with
this. Is there really a correct composition of this data, or is there
a consumer decision that is needed? We probably have a need to support
delivery of both "vest guess" composition AND full data to consumers.

Observed that we may not know how to do the "best" composition in all
cases, and therefore probably need to be able to expose uncertainty to
the watchers.

Observed that it may be important that the publisher understand what
the compositor is going to do with its data. This may lead to a need
for source-expressable composition preferences, which is hopefully a
"future" topic.

Proposed that we need to support both models.

Proposed that HGS' model would benefit watcher-specific composition.

Noted by chair: This means that an "original source" could publish
conflicting information.

Proposed that the presence document should be able to indicate the
"preferred" view among conflicting views, and that this would be
usable by "dumb" clients. Also noted that "outgoing" policy might
dictate which view is shown to any given watcher.

Proposed that there is no "one true answer" for composition.

Proposed that a timestamp is not enough to indicate the "preferred"
element out of a compositor.

Chair summary: Not acceptable for us to produce a lossy model. We want
the ability to pass through additional information. We understand that
this increases complexity. We will not explain everything, but will
provide a hint as to to which one of the conflicting elements is
recommended.


Issue: Sphere

If we have multiple elements, we may have conflicting sphere
information. This breaks the current model of using the default
composition policy to select which authorization policy applies.

Proposal: Allow separate algorithm (not same as default composition
policy) for determination of which conflicting variable is used for
authorization policy.

Much discussion followed.

Proposed that perhaps authorization policy should be driven by the
view that would be seen by the presentity as a watcher.



Issue: Mutiple Services with Same URI

Much discussion followed.

Noted that there are deployments that don't support GRUU and that some
are hestitant to make the solution GRUU dependent.

Noted that "Open" and "Closed" at a top-level are inadequate as soon
as there are multiple capabilities per device.

Discussion devolved into an apparent divide between model views.

Chair point: We keep talking about differentiating tuples based on
URI equivalency, and whether compositors group according to these same
comparisons. This necessitates that compositors be able to
ascertain the equivalency of two URIs, which might be difficult. We
appear to have no consensus on this at thsi time.

Summary: This is going to make a long list discussion, and we may not
have even stated the problem clearly.


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


From simple-bounces@ietf.org  Mon Dec  6 10:54:30 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24494;
	Mon, 6 Dec 2004 10:54:30 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLIR-000889-Mn; Mon, 06 Dec 2004 11:01:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8m-0005uB-Mk; Mon, 06 Dec 2004 10:51:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaOqZ-0002YB-8t
	for simple@megatron.ietf.org; Fri, 03 Dec 2004 20:36:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28481
	for <simple@ietf.org>; Fri, 3 Dec 2004 20:36:25 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaOwP-0003CI-Ks
	for simple@ietf.org; Fri, 03 Dec 2004 20:42:30 -0500
Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB41ZCvp000576
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 3 Dec 2004 19:35:13 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BCB558C0-4594-11D9-A939-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Date: Fri, 3 Dec 2004 19:35:10 -0600
To: Chris Boulton <cboulton@ubiquity.net>, Colin Perkins <csp@csperkins.org>,
        Cullen Jennings <fluffy@cisco.com>, Robert Sparks <RjS@xten.com>,
        Rohan Mahy <rohan@ekabal.com>, Adam Roach <adam@nostrum.com>,
        Hisham Khartabil <hisham.khartabil@telio.no>,
        Orit Levin <oritl@microsoft.com>,
        Joerg Ott <jo@informatik.uni-bremen.de>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: Simple WG <simple@ietf.org>
Subject: [Simple] MSRP: SDP usage concern
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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit

In the DC meeting, we discussed that MSRP's SDP usage should be 
reviewed in MMUSIC, or at least by people who are more expert in SDP.  
Colin Perkins and Joerg Ott looked at this, and suggested a change. 
(Many thanks to them for taking the time, and I hope they will jump in 
and correct me if I mischaracterize anything.)

The upshot of the proposal is that the fact that MSRP ignores the 
address in the sdp c-line, and the port and proto fields in the m-line. 
Instead, MSRP gets all of this from the first URL in the path a-line 
attribute. This deviates from the traditional usage in SDP, and causes 
confusion.

The proposed change is that the destination URL be broken into the 
appropriate parts and encoded into the c-line and m-line. For example 
(leaving out lines that don't change)

  c=IN IP4 alice.example.com
  m=message 9 msrp *
  a=path:msrp://a.example.com:7394/2s93i;tcp

would become:

  c=IN IP4 a.example.com
  m=message 7394 msrp/tcp *
  a=session:2s93i

The change would only be made for the destination URL. URLs for any 
relays would be expressed the same way they are now.

The advantage of this approach is that it more closely follows the 
spirit of SDP. This will be easier to understand for people who already 
know SDP. Existing SDP code could be reused more effectively.

The disadvantage of the proposed change is, it means the way an MSRP 
client determines the destination URL would be different depending on 
whether the URL represented the final destination or a relay. Instead 
of the current approach of simply copying the path attribute value into 
the To-Path header in MSRP messages,  a client would copy the path 
header value if exists, reconstitute the destination URL from the m and 
c lines, and append the destination URL to the path header value.

So, what do people think? (I note that we actually did something 
similar to this before we added the "path" attribute. )


Thanks!

Ben.



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


From simple-bounces@ietf.org  Mon Dec  6 10:54:55 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24531;
	Mon, 6 Dec 2004 10:54:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLIr-00088n-Ig; Mon, 06 Dec 2004 11:01:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8n-0005uG-81; Mon, 06 Dec 2004 10:51:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaWTf-0005dx-IL
	for simple@megatron.ietf.org; Sat, 04 Dec 2004 04:45:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15227
	for <simple@ietf.org>; Sat, 4 Dec 2004 04:45:16 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CaWZZ-0004nv-Rj
	for simple@ietf.org; Sat, 04 Dec 2004 04:51:26 -0500
Received: (qmail 24379 invoked by uid 65534); 4 Dec 2004 09:44:45 -0000
Received: from p5485659F.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.101.159)
	by mail.gmx.net (mp002) with SMTP; 04 Dec 2004 10:44:45 +0100
X-Authenticated: #1915285
Message-ID: <41B18709.1040502@gmx.de>
Date: Sat, 04 Dec 2004 10:44:41 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] Some thoughts on XCAP's resource architecture
References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>	<20041128012722.GA49273%ginga@ginganet.org>
	<41A9B79A.9020904@gmx.de> <41B12B9F.6000608@cisco.com>
In-Reply-To: <41B12B9F.6000608@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: "'simple@ietf.org'" <simple@ietf.org>, KAWAGUTI Ginga <g.kawaguti@ntt.com>,
        Lisa Dusseault <lisa@osafoundation.org>,
        HTTP working group <ietf-http-wg@w3.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> 
> Julian Reschke wrote:
> 
>> KAWAGUTI Ginga wrote:
>>
>>> ...
>>> XCAP's target document is usually written in UTF-8(it's XML),
>>
>>
>>
>> Unless XCAP says something normative, it could be any encoding. As far 
>> as I can tell, the actual decoding doesn't matter at all as long as it 
>> is one of the XML required ones (thus UTF-8 or UTF-16).
>>
>>> so XCAP requires Xpath stuff(utf-8) into URL part, which is usually
>>> considered as US-ASCII.
>>> There are ways to encode utf-8 string into URL part, but
>>> I don't think there's any unique, robust and common way for doing it.
>>
>>
>>
>> No matter what encoding the document uses, XCAP needs to define that 
>> mapping (and yes, that mapping needs to be based on UTF-8).
> 
> 
> This is a good point; I've gotten a private comment about this as well. 
> I think the simplest thing is to normatively state that all XML 
> documents managed by XCAP have to be utf-8 encoded. In terms of a 

That may be a bad choice if lots of your data is in characters that need 
multi-byte sequences, in which case UTF-16 may be more efficient. I 
think XCAP should simply stick with what XML requires (which is UTF-8 
and UTF-16, nothing more).

> mapping from UTF-8 strings into a URI, can you clarify why this is hard? 
> Isn't it just a matter of escape-coding the octet sequence associated 
> with non-ascii characters (I admit this is not my area of expertise and 
> I likely am missing something here).

This isn't hard, one just needs to define it.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

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


From simple-bounces@ietf.org  Mon Dec  6 10:55:43 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24626;
	Mon, 6 Dec 2004 10:55:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLJa-0008AO-OU; Mon, 06 Dec 2004 11:02:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8o-0005uM-0l; Mon, 06 Dec 2004 10:51:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaXrG-0000OO-NI
	for simple@megatron.ietf.org; Sat, 04 Dec 2004 06:13:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19929
	for <simple@ietf.org>; Sat, 4 Dec 2004 06:13:43 -0500 (EST)
Received: from mail.followap.com ([194.90.168.100] helo=MHAIFA.followap.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaXxB-0006Qw-Hy
	for simple@ietf.org; Sat, 04 Dec 2004 06:19:54 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 4 Dec 2004 13:03:51 +0200
Message-ID: <8993B20049600A40B0AEAFD6F736C9DF0113EA55@MHAIFA.followap.com>
X-MS-Has-Attach: yes
Thread-Topic: MSRP-09 Comments
Thread-Index: AcTZ8O/j4OO1MC6KTXqoxTX/514grA==
From: "Sharon Fridman" <Sharon.Fridman@followap.com>
To: <ben@estacado.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: simple@ietf.org
Subject: [Simple] MSRP-09 Comments
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="===============1519382966=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd

This is a multi-part message in MIME format.

--===============1519382966==
Content-class: urn:content-classes:message
Content-Type: multipart/related; type="multipart/alternative";
	boundary="----_=_NextPart_001_01C4D9F1.923FBBDC"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4D9F1.923FBBDC
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C4D9F1.923FBBDC"


------_=_NextPart_002_01C4D9F1.923FBBDC
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi!

=20

Small comment on MSRP version 9, Section 5.1 - the last 2 paragraphs
repeat the same sentence, and may need rephrasing, e.g:

*         "The ability to interrupt messages allows multiple sessions to
share a TCP connection..."

*         "The ability to interrupt message is needed so that TCP
connections can be shared"

=20

Thanks,

--Fridy / Followap


------_=_NextPart_002_01C4D9F1.923FBBDC
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h2
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l2 level2 lfo4;
	font-size:14.0pt;
	font-family:Arial;
	font-style:italic;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.Heading2text, li.Heading2text, div.Heading2text
	{margin-top:15.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l2 level2 lfo4;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
span.EmailStyle20
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:114831247;
	mso-list-template-ids:1740918248;
	mso-list-style-name:"Style Bulleted \(Latin\) Courier New \(Complex\) =
Courier New Before\:\.\.\.";}
@list l0:level1
	{mso-level-number-format:image;
	list-style-image:url("cid:image001.gif\@01C4DA01.B361A580");
	mso-level-text:\F0B7;
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;
	font-family:Symbol;
	color:windowtext;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:-20.7pt;
	mso-level-number-position:left;
	margin-left:-20.7pt;
	text-indent:-18.0pt;
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:12.0pt;
	mso-ascii-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:15.3pt;
	mso-level-number-position:left;
	margin-left:15.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:51.3pt;
	mso-level-number-position:left;
	margin-left:51.3pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:87.3pt;
	mso-level-number-position:left;
	margin-left:87.3pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:123.3pt;
	mso-level-number-position:left;
	margin-left:123.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:159.3pt;
	mso-level-number-position:left;
	margin-left:159.3pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:195.3pt;
	mso-level-number-position:left;
	margin-left:195.3pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:231.3pt;
	mso-level-number-position:left;
	margin-left:231.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l1
	{mso-list-id:233779871;
	mso-list-type:hybrid;
	mso-list-template-ids:-1726289240 67698689 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:54.0pt;
	mso-level-number-position:left;
	margin-left:54.0pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l1:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:90.0pt;
	mso-level-number-position:left;
	margin-left:90.0pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l1:level4
	{mso-level-tab-stop:126.0pt;
	mso-level-number-position:left;
	margin-left:126.0pt;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:162.0pt;
	mso-level-number-position:left;
	margin-left:162.0pt;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:198.0pt;
	mso-level-number-position:left;
	margin-left:198.0pt;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:234.0pt;
	mso-level-number-position:left;
	margin-left:234.0pt;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:270.0pt;
	mso-level-number-position:left;
	margin-left:270.0pt;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:306.0pt;
	mso-level-number-position:left;
	margin-left:306.0pt;
	text-indent:-18.0pt;}
@list l2
	{mso-list-id:1672835366;
	mso-list-template-ids:-522448532;}
@list l2:level1
	{mso-level-text:"Chapter %1\.";
	mso-level-tab-stop:0cm;
	mso-level-number-position:right;
	margin-left:0cm;
	text-indent:0cm;}
@list l2:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:28.8pt;
	mso-level-number-position:left;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	mso-ansi-font-style:normal;}
@list l2:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	margin-left:36.0pt;
	text-indent:-36.0pt;
	mso-ansi-font-style:normal;}
@list l2:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:97.2pt;
	mso-level-number-position:left;
	margin-left:97.2pt;
	text-indent:-43.2pt;}
@list l2:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:50.4pt;
	mso-level-number-position:left;
	margin-left:50.4pt;
	text-indent:-50.4pt;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	mso-ansi-font-weight:bold;
	mso-ansi-font-style:normal;}
@list l2:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:57.6pt;
	mso-level-number-position:left;
	margin-left:57.6pt;
	text-indent:-57.6pt;}
@list l2:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:64.8pt;
	mso-level-number-position:left;
	margin-left:64.8pt;
	text-indent:-64.8pt;}
@list l2:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	margin-left:72.0pt;
	text-indent:-72.0pt;}
@list l2:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:79.2pt;
	mso-level-number-position:left;
	margin-left:79.2pt;
	text-indent:-79.2pt;}
@list l3
	{mso-list-id:1827085443;
	mso-list-template-ids:448292822;}
@list l3:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l3:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l3:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</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'>S</span></font><font size=3D2 face=3DArial><span =
lang=3DIT
style=3D'font-size:10.0pt;font-family:Arial'>mall </span></font><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>comment =
on MSRP
version 9, Section 5.1 - the last 2 paragraphs repeat the same sentence, =
and
may need rephrasing, e.g:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:18.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo7'><![if !supportLists]><font
size=3D2 face=3DSymbol><span =
style=3D'font-size:10.0pt;font-family:Symbol'><span
style=3D'mso-list:Ignore'>&middot;<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><span dir=3DLTR><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&#8220;The ability
to interrupt messages allows multiple sessions to share a TCP
connection&#8230;&#8221;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:18.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo7'><![if !supportLists]><font
size=3D2 face=3DSymbol><span =
style=3D'font-size:10.0pt;font-family:Symbol'><span
style=3D'mso-list:Ignore'>&middot;<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><span dir=3DLTR><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&#8220;The ability
to interrupt message is needed so that TCP connections can be =
shared&#8221;<o:p></o:p></span></font></span></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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>--Fridy / Followap<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_002_01C4D9F1.923FBBDC--

------_=_NextPart_001_01C4D9F1.923FBBDC
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@01C4DA01.B361A580>
Content-Description: image001.gif
Content-Location: image001.gif
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhDwAPAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAY
AAAADG1zT1BNU09GRklDRTkuMERuJlAzACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIC
AQEGiroUzgAh+QQBAAABACwAAAAADwAPAIb/99jAwMD/0BP/1Cf/2Dv/32IAAABSUf94eP+Mi/+f
nv/Fxf//8LD/88QFBP8sK///9MT/+Nj/77D/88X/6In/8LH/2tr/v7//sbH/o6P/h4f/eXn/1zv/
4GL/z8//s7P/pqb/mJf/xMT/qKf/mpr/jIz/cXD/YmL/ra3/kZL/hIP/dXb/Wlr/TEz/oqL/hob/
eHf/amr/Tk7/QUD/lpb/enr/bW3/Xl//0BSfn//Gxf95d/+Li///6Ir/54l5eP94d/9SUv8sKv8r
K/8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMHh4ABgoOEhYaCBoeDAgMcBQYUFQ0AhjgDBB0GPgyThowEj5sQEZ6XjxQSE6SF
lqCQnJQBNDU2N5YcmT0SnQEuLzAxMjMODwYHCDw5OgEoKSorLC0OQsZACQoLASIjJCUmJ9PGCNfZ
Hh8gIQbq6+wGFhcYGRobDkPGP9fLhsQGQTs82BQFSFQoEAA7

------_=_NextPart_001_01C4D9F1.923FBBDC--


--===============1519382966==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1519382966==--



From simple-bounces@ietf.org  Mon Dec  6 10:56:37 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24743;
	Mon, 6 Dec 2004 10:56:37 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLKV-0008Cc-Nm; Mon, 06 Dec 2004 11:03:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8o-0005uR-Mx; Mon, 06 Dec 2004 10:51:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaZXL-0008Vy-O3
	for simple@megatron.ietf.org; Sat, 04 Dec 2004 08:01:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26400
	for <simple@ietf.org>; Sat, 4 Dec 2004 08:01:18 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CaZdH-0008T9-Ap
	for simple@ietf.org; Sat, 04 Dec 2004 08:07:28 -0500
Received: (qmail 19784 invoked by uid 65534); 4 Dec 2004 13:00:45 -0000
Received: from p5485659F.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.101.159)
	by mail.gmx.net (mp021) with SMTP; 04 Dec 2004 14:00:45 +0100
X-Authenticated: #1915285
Message-ID: <41B1B4F8.3060503@gmx.de>
Date: Sat, 04 Dec 2004 14:00:40 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] Some thoughts on XCAP's resource architecture
References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>
	<41B10A54.5060209@cisco.com>
In-Reply-To: <41B10A54.5060209@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: Lisa Dusseault <lisa@osafoundation.org>,
        HTTP working group <ietf-http-wg@w3.org>,
        "'simple@ietf.org'" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> ...
>> 2a) HTTP implementation barriers.  The last HTTP server I developed 
>> would have to be rearchitected in several places to handle XCAP's 
>> interdependencies, work beyond what you'd expect from adding XCAP 
>> support.  Throughout the server, the code uses exact matching of URLs 
>> to figure out what to do -- not URL pattern matching. So for example:
>>  - The way ETags were generated and stored and changed would have to 
>> be thrown out because ETags were generated independently for every 
>> resource.
>>  - Since resources were independent, write requests for different 
>> resources could be handled concurrently with ease, but that would have 
>> to change.
> 
> 
> The proof is in the implementations; we have a few already, and those 
> folks have posted here that they havent seen these problems.

And anyway (already pointed out earlier), an HTTP server that supports 
WebDAV namespace operations already can't handle etags on a per-resource 
basis. That approach simply doesn't work.

 > ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

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


From simple-bounces@ietf.org  Mon Dec  6 10:59:44 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25001;
	Mon, 6 Dec 2004 10:59:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLNW-0008HK-Gn; Mon, 06 Dec 2004 11:06:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8p-0005uW-DJ; Mon, 06 Dec 2004 10:51:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaaSj-00012l-Gp
	for simple@megatron.ietf.org; Sat, 04 Dec 2004 09:00:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00805
	for <simple@ietf.org>; Sat, 4 Dec 2004 09:00:35 -0500 (EST)
Received: from mail.followap.com ([194.90.168.100] helo=MHAIFA.followap.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaaYg-0001Km-38
	for simple@ietf.org; Sat, 04 Dec 2004 09:06:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 4 Dec 2004 15:49:55 +0200
Message-ID: <8993B20049600A40B0AEAFD6F736C9DF0113EA5A@MHAIFA.followap.com>
X-MS-Has-Attach: yes
Thread-Topic: MIME correction - draft-ietf-simple-partial-publish-01 
Thread-Index: AcTaCCJ3YJLveiY7SlC9jQW3Bg+/zg==
From: "Sharon Fridman" <Sharon.Fridman@followap.com>
To: <aki.niemi@nokia.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: simple@ietf.org
Subject: [Simple] MIME correction - draft-ietf-simple-partial-publish-01 
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="===============1716136436=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c

This is a multi-part message in MIME format.

--===============1716136436==
Content-class: urn:content-classes:message
Content-Type: multipart/related; type="multipart/alternative";
	boundary="----_=_NextPart_001_01C4DA08.C46844BF"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4DA08.C46844BF
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C4DA08.C46844BF"


------_=_NextPart_002_01C4DA08.C46844BF
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Aki,

=20

The MIME type in partial PIDF format, as well as that indicated in 4.1
and 4.3 of aobve is application/pidf-diff+xml.=20

However section 3.2 indicated the older application/pidf+partial+xml.

=20

Cheers,

Fridy / Followap


------_=_NextPart_002_01C4DA08.C46844BF
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>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h2
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l1 level2 lfo2;
	font-size:14.0pt;
	font-family:Arial;
	font-style:italic;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.Heading2text, li.Heading2text, div.Heading2text
	{margin-top:15.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l1 level2 lfo2;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:114831247;
	mso-list-template-ids:1740918248;
	mso-list-style-name:"Style Bulleted \(Latin\) Courier New \(Complex\) =
Courier New Before\:\.\.\.";}
@list l0:level1
	{mso-level-number-format:image;
	list-style-image:url("cid:image001.gif\@01C4DA18.E5E49690");
	mso-level-text:\F0B7;
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;
	font-family:Symbol;
	color:windowtext;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:-20.7pt;
	mso-level-number-position:left;
	margin-left:-20.7pt;
	text-indent:-18.0pt;
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:12.0pt;
	mso-ascii-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:15.3pt;
	mso-level-number-position:left;
	margin-left:15.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:51.3pt;
	mso-level-number-position:left;
	margin-left:51.3pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:87.3pt;
	mso-level-number-position:left;
	margin-left:87.3pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:123.3pt;
	mso-level-number-position:left;
	margin-left:123.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:159.3pt;
	mso-level-number-position:left;
	margin-left:159.3pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:195.3pt;
	mso-level-number-position:left;
	margin-left:195.3pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:231.3pt;
	mso-level-number-position:left;
	margin-left:231.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l1
	{mso-list-id:1672835366;
	mso-list-template-ids:-522448532;}
@list l1:level1
	{mso-level-text:"Chapter %1\.";
	mso-level-tab-stop:0cm;
	mso-level-number-position:right;
	margin-left:0cm;
	text-indent:0cm;}
@list l1:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:28.8pt;
	mso-level-number-position:left;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	mso-ansi-font-style:normal;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	margin-left:36.0pt;
	text-indent:-36.0pt;
	mso-ansi-font-style:normal;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:97.2pt;
	mso-level-number-position:left;
	margin-left:97.2pt;
	text-indent:-43.2pt;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:50.4pt;
	mso-level-number-position:left;
	margin-left:50.4pt;
	text-indent:-50.4pt;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	mso-ansi-font-weight:bold;
	mso-ansi-font-style:normal;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:57.6pt;
	mso-level-number-position:left;
	margin-left:57.6pt;
	text-indent:-57.6pt;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:64.8pt;
	mso-level-number-position:left;
	margin-left:64.8pt;
	text-indent:-64.8pt;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	margin-left:72.0pt;
	text-indent:-72.0pt;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:79.2pt;
	mso-level-number-position:left;
	margin-left:79.2pt;
	text-indent:-79.2pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</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 Aki,<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'>The MIME type in partial PIDF format, as well as that
indicated in 4.1 and 4.3 of aobve is application/pidf-diff+xml. =
<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'>However section 3.2 indicated the older
application/pidf+partial+xml.<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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Cheers,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Fridy / Followap<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_002_01C4DA08.C46844BF--

------_=_NextPart_001_01C4DA08.C46844BF
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@01C4DA18.E5E49690>
Content-Description: image001.gif
Content-Location: image001.gif
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhDwAPAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAY
AAAADG1zT1BNU09GRklDRTkuMERuJlAzACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIC
AQEGiroUzgAh+QQBAAABACwAAAAADwAPAIb/99jAwMD/0BP/1Cf/2Dv/32IAAABSUf94eP+Mi/+f
nv/Fxf//8LD/88QFBP8sK///9MT/+Nj/77D/88X/6In/8LH/2tr/v7//sbH/o6P/h4f/eXn/1zv/
4GL/z8//s7P/pqb/mJf/xMT/qKf/mpr/jIz/cXD/YmL/ra3/kZL/hIP/dXb/Wlr/TEz/oqL/hob/
eHf/amr/Tk7/QUD/lpb/enr/bW3/Xl//0BSfn//Gxf95d/+Li///6Ir/54l5eP94d/9SUv8sKv8r
K/8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMHh4ABgoOEhYaCBoeDAgMcBQYUFQ0AhjgDBB0GPgyThowEj5sQEZ6XjxQSE6SF
lqCQnJQBNDU2N5YcmT0SnQEuLzAxMjMODwYHCDw5OgEoKSorLC0OQsZACQoLASIjJCUmJ9PGCNfZ
Hh8gIQbq6+wGFhcYGRobDkPGP9fLhsQGQTs82BQFSFQoEAA7

------_=_NextPart_001_01C4DA08.C46844BF--


--===============1716136436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1716136436==--



From simple-bounces@ietf.org  Mon Dec  6 11:00:34 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25112;
	Mon, 6 Dec 2004 11:00:34 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLOK-0008IY-Jc; Mon, 06 Dec 2004 11:07:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8q-0005uf-RX; Mon, 06 Dec 2004 10:51:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CawCa-0006Za-T2
	for simple@megatron.ietf.org; Sun, 05 Dec 2004 08:13:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05207
	for <simple@ietf.org>; Sun, 5 Dec 2004 08:13:23 -0500 (EST)
Received: from mail.followap.com ([194.90.168.100] helo=MHAIFA.followap.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CawIj-0006kT-Lp
	for simple@ietf.org; Sun, 05 Dec 2004 08:19:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 5 Dec 2004 15:09:55 +0200
Message-ID: <8993B20049600A40B0AEAFD6F736C9DF0113EC48@MHAIFA.followap.com>
X-MS-Has-Attach: yes
Thread-Topic: Comments on rpid-04 
Thread-Index: AcTayIvdzsRJ8UL3RVCecY86gR+y5A==
From: "Sharon Fridman" <Sharon.Fridman@followap.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <vkg@lucent.com>,
        <pkzivat@cisco.com>, <jdrosen@dynamicsoft.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6c15d82a53e26283536b4a751453103
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: simple@ietf.org
Subject: [Simple] Comments on rpid-04 
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="===============0545237828=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 233de1b21593fc0f4cdf285406dca0da

This is a multi-part message in MIME format.

--===============0545237828==
Content-class: urn:content-classes:message
Content-Type: multipart/related; type="multipart/alternative";
	boundary="----_=_NextPart_001_01C4DACB.B6DD9100"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4DACB.B6DD9100
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C4DACB.B6DD9100"


------_=_NextPart_002_01C4DACB.B6DD9100
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Some minor comments on draft-ietf-simple-rpid-04:

=20

1.	It is not clear in 3.1 what is a characteristic and what is
dynamic status
2.	3.8 and schema in 5.2 indicate <service-class> but 3.1 mentions
<service-type>
3.	The example in 4 seems obsolete, few sample:

	*	<activities> is under a tuple in the example of 4, where
it is clearly indicated in 3.1 and 3.2 that it belongs to a person
	*	<place-type> is under a tuple in the example of 4, where
it is clearly indicated in 3.1 and 3.5 that it belongs to a person
	*	<idle> is rpid-03 and not present here - need
<user-input>
	*	<timestamp> is in rpid-03 and not present here - may
want to use <timezone>

4.	The <text> element on mood shown in the sample is not clear from
section 3.4
5.	Schema shows minOccurs 0 for <activity> within <activities>, but
text in 3.2 states "one or more elements"
6.	According to schema <timezone> may also have since & until
attributes - and it is not mentioned in 3.2 with the rest.
7.	<user-input> is both in 5.4, 5.3 and 5.2. I guess that 5.4 is
for the device (following the text in 3.1). However it is not explained
or clear why it is both characteristic and status for a service (e.g.
under tuple and under tuple | status). It is somewhat confusing.
8.	<privacy> is also in 5.3 and 5.4. Please clear this as well, as
the text in 3.1 mention it is for a service under tuple.=20

=20

Best Regards,

--Fridy / Followap


------_=_NextPart_002_01C4DACB.B6DD9100
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h2
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l3 level2 lfo4;
	font-size:14.0pt;
	font-family:Arial;
	font-style:italic;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.Heading2text, li.Heading2text, div.Heading2text
	{margin-top:15.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l3 level2 lfo4;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
p.heading2text0, li.heading2text0, div.heading2text0
	{margin-top:15.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l3 level2 lfo4;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
span.EmailStyle21
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:114831247;
	mso-list-template-ids:1740918248;
	mso-list-style-name:"Style Bulleted \(Latin\) Courier New \(Complex\) =
Courier New Before\:\.\.\.";}
@list l0:level1
	{mso-level-number-format:image;
	list-style-image:url("cid:image001.gif\@01C4DADB.AD80D110");
	mso-level-text:\F0B7;
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;
	font-family:Symbol;
	color:windowtext;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:-20.7pt;
	mso-level-number-position:left;
	margin-left:-20.7pt;
	text-indent:-18.0pt;
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:12.0pt;
	mso-ascii-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:15.3pt;
	mso-level-number-position:left;
	margin-left:15.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:51.3pt;
	mso-level-number-position:left;
	margin-left:51.3pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:87.3pt;
	mso-level-number-position:left;
	margin-left:87.3pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:123.3pt;
	mso-level-number-position:left;
	margin-left:123.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:159.3pt;
	mso-level-number-position:left;
	margin-left:159.3pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:195.3pt;
	mso-level-number-position:left;
	margin-left:195.3pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:231.3pt;
	mso-level-number-position:left;
	margin-left:231.3pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l1
	{mso-list-id:854156280;
	mso-list-type:hybrid;
	mso-list-template-ids:-592536644 67698703 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2
	{mso-list-id:1247497483;
	mso-list-template-ids:-570252278;}
@list l2:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l3
	{mso-list-id:1672835366;
	mso-list-template-ids:-522448532;}
@list l3:level1
	{mso-level-text:"Chapter %1\.";
	mso-level-tab-stop:0cm;
	mso-level-number-position:right;
	margin-left:0cm;
	text-indent:0cm;}
@list l3:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:28.8pt;
	mso-level-number-position:left;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	mso-ansi-font-style:normal;}
@list l3:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	margin-left:36.0pt;
	text-indent:-36.0pt;
	mso-ansi-font-style:normal;}
@list l3:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:97.2pt;
	mso-level-number-position:left;
	margin-left:97.2pt;
	text-indent:-43.2pt;}
@list l3:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:50.4pt;
	mso-level-number-position:left;
	margin-left:50.4pt;
	text-indent:-50.4pt;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	mso-ansi-font-weight:bold;
	mso-ansi-font-style:normal;}
@list l3:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:57.6pt;
	mso-level-number-position:left;
	margin-left:57.6pt;
	text-indent:-57.6pt;}
@list l3:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:64.8pt;
	mso-level-number-position:left;
	margin-left:64.8pt;
	text-indent:-64.8pt;}
@list l3:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	margin-left:72.0pt;
	text-indent:-72.0pt;}
@list l3:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:79.2pt;
	mso-level-number-position:left;
	margin-left:79.2pt;
	text-indent:-79.2pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</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'>Some minor comments on =
draft-ietf-simple-rpid-04:<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:0cm' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>It is not clear in 3.1 =
what is
     a characteristic and what is dynamic =
status<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>3.8 and schema in 5.2 =
indicate
     &lt;service-class&gt; but 3.1 mentions =
&lt;service-type&gt;<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>The example in 4 seems
     obsolete, few sample:<o:p></o:p></span></font></li>
 <ul style=3D'margin-top:0cm' type=3Dcircle>
  <li class=3DMsoNormal style=3D'mso-list:l1 level2 lfo7'><font size=3D2 =
face=3DArial><span
      style=3D'font-size:10.0pt;font-family:Arial'>&lt;activities&gt; is =
under a
      tuple in the example of 4, where it is clearly indicated in 3.1 =
and 3.2
      that it belongs to a person<o:p></o:p></span></font></li>
  <li class=3DMsoNormal style=3D'mso-list:l1 level2 lfo7'><font size=3D2 =
face=3DArial><span
      style=3D'font-size:10.0pt;font-family:Arial'>&lt;place-type&gt; is =
under a
      tuple in the example of 4, where it is clearly indicated in 3.1 =
and 3.5
      that it belongs to a person<o:p></o:p></span></font></li>
  <li class=3DMsoNormal style=3D'mso-list:l1 level2 lfo7'><font size=3D2 =
face=3DArial><span
      style=3D'font-size:10.0pt;font-family:Arial'>&lt;idle&gt; is =
rpid-03 and
      not present here &#8211; need =
&lt;user-input&gt;<o:p></o:p></span></font></li>
  <li class=3DMsoNormal style=3D'mso-list:l1 level2 lfo7'><font size=3D2 =
face=3DArial><span
      style=3D'font-size:10.0pt;font-family:Arial'>&lt;timestamp&gt; is =
in
      rpid-03 and not present here &#8211; may want to use =
&lt;timezone&gt;<o:p></o:p></span></font></li>
 </ul>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>The &lt;text&gt; =
element on
     mood shown in the sample is not clear from section =
3.4<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>Schema shows minOccurs =
0 for &lt;activity&gt;
     within &lt;activities&gt;, but text in 3.2 states &#8220;one or =
more
     elements&#8221;<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>According to schema
     &lt;timezone&gt; may also have since &amp; until attributes &#8211; =
and it
     is not mentioned in 3.2 with the =
rest.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>&lt;user-input&gt; is =
both in 5.4,
     5.3 and 5.2. I guess that 5.4 is for the device (following the text =
in
     3.1). However it is not explained or clear why it is both =
characteristic
     and status for a service (e.g. under tuple and under tuple | =
status). It
     is somewhat confusing.<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l1 level1 lfo7'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>&lt;privacy&gt; is =
also in 5.3
     and 5.4. Please clear this as well, as the text in 3.1 mention it =
is for a
     service under tuple. <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'>Best Regards,<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'>--Fridy / Followap<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_002_01C4DACB.B6DD9100--

------_=_NextPart_001_01C4DACB.B6DD9100
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@01C4DADB.AD80D110>
Content-Description: image001.gif
Content-Location: image001.gif
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhDwAPAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAY
AAAADG1zT1BNU09GRklDRTkuMERuJlAzACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIC
AQEGiroUzgAh+QQBAAABACwAAAAADwAPAIb/99jAwMD/0BP/1Cf/2Dv/32IAAABSUf94eP+Mi/+f
nv/Fxf//8LD/88QFBP8sK///9MT/+Nj/77D/88X/6In/8LH/2tr/v7//sbH/o6P/h4f/eXn/1zv/
4GL/z8//s7P/pqb/mJf/xMT/qKf/mpr/jIz/cXD/YmL/ra3/kZL/hIP/dXb/Wlr/TEz/oqL/hob/
eHf/amr/Tk7/QUD/lpb/enr/bW3/Xl//0BSfn//Gxf95d/+Li///6Ir/54l5eP94d/9SUv8sKv8r
K/8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB
AgMBAgMBAgMBAgMHh4ABgoOEhYaCBoeDAgMcBQYUFQ0AhjgDBB0GPgyThowEj5sQEZ6XjxQSE6SF
lqCQnJQBNDU2N5YcmT0SnQEuLzAxMjMODwYHCDw5OgEoKSorLC0OQsZACQoLASIjJCUmJ9PGCNfZ
Hh8gIQbq6+wGFhcYGRobDkPGP9fLhsQGQTs82BQFSFQoEAA7

------_=_NextPart_001_01C4DACB.B6DD9100--


--===============0545237828==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0545237828==--



From simple-bounces@ietf.org  Mon Dec  6 11:01:37 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25253;
	Mon, 6 Dec 2004 11:01:37 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLPL-0008L0-Kz; Mon, 06 Dec 2004 11:08:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8r-0005uk-KC; Mon, 06 Dec 2004 10:51:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb040-00015Q-Qd
	for simple@megatron.ietf.org; Sun, 05 Dec 2004 12:20:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22916
	for <simple@ietf.org>; Sun, 5 Dec 2004 12:20:46 -0500 (EST)
Received: from mail.shareable.org ([81.29.64.88])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb0AC-0003Qa-4H
	for simple@ietf.org; Sun, 05 Dec 2004 12:27:12 -0500
Received: from mail.shareable.org (localhost [127.0.0.1])
	by mail.shareable.org (8.12.8/8.12.8) with ESMTP id iB5HKi81009018;
	Sun, 5 Dec 2004 17:20:44 GMT
Received: (from jamie@localhost)
	by mail.shareable.org (8.12.8/8.12.8/Submit) id iB5HKhui009016;
	Sun, 5 Dec 2004 17:20:43 GMT
Date: Sun, 5 Dec 2004 17:20:43 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] Some thoughts on XCAP's resource architecture
Message-ID: <20041205172043.GA8021@mail.shareable.org>
References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>
	<41B10A54.5060209@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41B10A54.5060209@cisco.com>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: Lisa Dusseault <lisa@osafoundation.org>,
        HTTP working group <ietf-http-wg@w3.org>,
        "'simple@ietf.org'" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4

Jonathan Rosenberg wrote:
> >1a) HTTP intermediaries and scaling: caches aren't designed to cache 
> >huge numbers of tiny resources.  It would probably be wise to disable 
> >caching on XCAP responses.
> 
> This is described in section 9 of xcap, which more or less says that you 
> will want to disable caching for dynamic resources - ones frequently 
> written by clients or otherwise. However, there are application usages 
> where the data is primarily read-only. In that case, its reasonable to 
> allow caching of those resources.
> 
> As such, there is an interaction with xcap and caching, but not because 
> the resources are small - because they may be dynamic. This is an issue 
> for any http resource.

xcap resources may overlap, and that means they share content.  This
content has to be duplicated in the HTTP caching model, and that is a
sense where some usages don't scale optimally.

It would be hard to design a caching model which did scale optimally.

> Jamie Lokier wrote:
> >Lisa Dusseault wrote:
> >
> >>>If you have multiple changes to make to a 1 MB or smaller document, 
> >>>batch them up together if possible, even if it requires uploading the 
> >>>whole document afresh.  The current design of XCAP encourages changes 
> >>>to be made independently, and each change will require a full 
> >>>round-trip (no pipelining possible because you need to wait for the 
> >>>server to respond with an ETag each time).
> >
> >
> >That seems like a flaw which should be fixed.
> 
> I have to disagree with Lisa here, this is not a constraint on xcap. You 
> do not have to wait for the etag to send the next request. You only have 
> to wait for the etag if you wish your next change to be conditioned on 
> the fact that the document hasn't been modified since your last change. 
> That's true of http generally, and true here too - its the defining 
> purpose of the If-* headers. The various application usages talk about 
> ways in whcih the documents are structured so that one doesn't need to 
> used conditional PUts'. In that case, feel free to pipeline.

In other words, you can only batch a group of small updates when you
want to apply them unconditionally.

The usual way to update a resource where data should never be lost or
the update is logically an atomic data-dependent operation is to do
them conditionally, using If-* headers.

This works fine in HTTP for updating a single resource.

It also works fine in HTTP for updating parts of a resource, when
using the not yet standardised PATCH operation.

But with XCAP, when a group of small updates is to be applied
conditionally, then a round trip time will be incurred between each
small update.

This is very slow for many small updates.  Combining the updates to
simply write a large portion of a resource does not scale if it's a
very large resource and only small, sparse updates are required
(e.g. when updating an entry an an XML database).

The suggested workaround is to restructure the XML documents so that
updates are done unconditionally.

In other words, things like XML databases would be wrapped in some
kind of "front end" such that the view seen through XCAP doesn't
correspond directly with the tree structure of the underlying data
resource.  A transformed view allows unconditional PUTs to be
translated to atomic logical operations on the underlying data resource.

This seems to me to defeat much of the point of XCAP, which is to
remove the need for application-specific APIs for accessing and
updating data resource parts.

It is not hard to think up solutions which allow updates of many small
parts of an XCAP as one effective operation.

Because atomic updates are useful, it would make sense to do compound
updates in a single HTTP operation.  Merely finding a way to pipeline
the updates would _not_ be adequate.

The obvious methods are to define a compound update PUT form,
e.g. using multipart/something, or to propose an extension to XCAP
which uses PATCH.

It would be generally useful to have a PATCH format which is good for
updating parts of XML documents, but that is probably best left as
another engineering problem.

Meanwhile, a multipart/something PUT form would be quite easy to
define, and it could be an optional but recommended feature.

-- Jamie

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


From simple-bounces@ietf.org  Mon Dec  6 11:03:15 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25439;
	Mon, 6 Dec 2004 11:03:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLQv-0008OT-V5; Mon, 06 Dec 2004 11:09:54 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbL8s-0005ve-CU; Mon, 06 Dec 2004 10:51:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbE1O-0007KQ-7T
	for simple@megatron.ietf.org; Mon, 06 Dec 2004 03:15:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10378
	for <simple@ietf.org>; Mon, 6 Dec 2004 03:15:00 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CbE7h-0003vU-TD
	for simple@ietf.org; Mon, 06 Dec 2004 03:21:34 -0500
Received: (qmail 18484 invoked by uid 65534); 6 Dec 2004 08:14:24 -0000
Received: from pD9E518B3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.179)
	by mail.gmx.net (mp017) with SMTP; 06 Dec 2004 09:14:24 +0100
X-Authenticated: #1915285
Message-ID: <41B414DA.5020803@gmx.de>
Date: Mon, 06 Dec 2004 09:14:18 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kawaguti Ginga <g.kawaguti@ntt.com>
Subject: Re: [Simple] Some thoughts on XCAP's resource architecture
References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org>
	<20041128012722.GA49273%ginga@ginganet.org>
	<41A9B79A.9020904@gmx.de> <41B12B9F.6000608@cisco.com>
	<41B18709.1040502@gmx.de> <20041206020711.GO3856@ntt.com>
In-Reply-To: <20041206020711.GO3856@ntt.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 06 Dec 2004 10:51:06 -0500
Cc: Lisa Dusseault <lisa@osafoundation.org>,
        HTTP working group <ietf-http-wg@w3.org>,
        "'simple@ietf.org'" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit

Kawaguti Ginga wrote:
> In Sat, Dec 04, 2004 at 10:44:41AM +0100,
> Julian Reschke <julian.reschke@gmx.de> wrote:
> 
>>That may be a bad choice if lots of your data is in characters that need 
>>multi-byte sequences, in which case UTF-16 may be more efficient. I 
>>think XCAP should simply stick with what XML requires (which is UTF-8 
>>and UTF-16, nothing more).
> 
> 
> I agree that "hard-assumption of UTF-8 usage" is a bad choice.
> UTF-8 is only a DEFAULT encoding for XML standard.

...it is one of two required encoding...

> Yes it is recommended to use UTF-8, but there are many other XML documents
> based on other encodings (not only UTF-16, but many more).

No, it's not in any way "more" recommended than UTF-16.

> If XCAP is intended to be very specific protocol only for
> some limited XML documents, then "all documents are UTF-8(and/or UTF-16)" 
> assumption might work, but it's a bad idea for general protocol design.

You need to make this assumption for full portability. These are the 
only encodings a conforming XML parser has to understand.

> There are many ways to specify encodings in a XCAP-only-way,
> like appending "http://.../...?encoding=utf-8?...",
> but they're not HTTP-standard way.

Why would you want to do that? Anyway: if you really need to, you can 
use the Accept-Charset request header 
(<http://greenbytes.de/tech/webdav/rfc2616.html#header.accept-charset>).

> And something more, URL string size limitation.
> "% encoded" UTF-8 string might suffer even more on this restriction.

Even more than what? What alternative are you proposing?

> Julian's previous mail:
> 
>>>If that argument was in body part(header might also be recepted),
>>>this consideration is much less problem, because there are ways to
>>>declare encodings, and usual gateways/clients are aware of them.
>>
>>Don't understand. How are you sending the document selector inside the 
>>request body for PUT?
> 
> 
> For generic HTTP PUT, there's no way, as denoted in your comment.
> My consideration was to use something like SOAP envelope.
> It shouldn't be "PUT" anymore, and it should be used over
> some original rule anyway.

But then we're not talking about an HTTP *application* anymore, but only 
about tunneling *through* HTTP.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

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


From qkjrchbq@msn.com  Tue Dec  7 09:34:14 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05215;
	Tue, 7 Dec 2004 09:34:14 -0500 (EST)
Received: from [218.49.108.215] (helo=132.151.6.1)
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1CbgWT-00053c-RA; Tue, 07 Dec 2004 09:41:03 -0500
Received: from seedbed [234.3.132.228] (helo=ladylike.endosperm.dearriba.com)
	by smtp2.cistron.nl with esmtp (administrate 3.35 #1 (caught))
	id 716LFL-0078PT-67
Message-ID: <34848223144732.R37421@kennedy.noc.lipton.gr>
Sender: freeradius-devel-qkjrchbq@msn.com
X-Mailman-Version: 2.0.1
Date: Tue, 07 Dec 2004 20:28:57 +0600
From: "Luke Champion" <qkjrchbq@msn.com>
To: simple@ietf.org
Subject:  Best Med^s Here Simple
X-Spam-Score: 8.2 (++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab


The L0west price of all med's is here. 

 V1a'gra - $199.95 (60 pil|s)
 Va|ium -	$259.95 (100 pil|s)
 Cia|is -	$189.95 (30 pi||s)
 Xa'nax - $233.95 (100 pi|ls)
and many m0reeee.....

We are the bes't available nowadays

http://missedalesson.com/2/sale/?wid=200007








This is 1 -time mailing. N0-re m0val are re'qui-red
bi5WOAeKjrGZ0MdtSRNcr81pVr5q4tdIGKkMoi5TFnlCZmV6KQZ7mDaTx2


From simple-bounces@ietf.org  Tue Dec  7 11:04:25 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17578;
	Tue, 7 Dec 2004 11:04:25 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbhvl-0007Qw-Vu; Tue, 07 Dec 2004 11:11:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbhej-0003Fx-9g; Tue, 07 Dec 2004 10:53:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbLdQ-00066D-JZ
	for simple@megatron.ietf.org; Mon, 06 Dec 2004 11:22:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26834
	for <simple@ietf.org>; Mon, 6 Dec 2004 11:22:46 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbLjo-0000M8-DU
	for simple@ietf.org; Mon, 06 Dec 2004 11:29:24 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 06 Dec 2004 08:28:02 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB6GM4IT002975;
	Mon, 6 Dec 2004 08:22:05 -0800 (PST)
Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id ANM39272; Mon, 6 Dec 2004 11:22:10 -0500 (EST)
Message-ID: <41B48732.8030209@cisco.com>
Date: Mon, 06 Dec 2004 11:22:10 -0500
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] MSRP: SDP usage concern
References: <BCB558C0-4594-11D9-A939-000D93B0AE1A@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 07 Dec 2004 10:53:35 -0500
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        Chris Boulton <cboulton@ubiquity.net>, Adam Roach <adam@nostrum.com>,
        Simple WG <simple@ietf.org>, Joerg Ott <jo@informatik.uni-bremen.de>,
        Robert Sparks <RjS@xten.com>, Colin Perkins <csp@csperkins.org>,
        Orit Levin <oritl@microsoft.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> In the DC meeting, we discussed that MSRP's SDP usage should be reviewed 
> in MMUSIC, or at least by people who are more expert in SDP.  Colin 
> Perkins and Joerg Ott looked at this, and suggested a change. (Many 
> thanks to them for taking the time, and I hope they will jump in and 
> correct me if I mischaracterize anything.)
> 
> The upshot of the proposal is that the fact that MSRP ignores the 
> address in the sdp c-line, and the port and proto fields in the m-line. 
> Instead, MSRP gets all of this from the first URL in the path a-line 
> attribute. This deviates from the traditional usage in SDP, and causes 
> confusion.
> 
> The proposed change is that the destination URL be broken into the 
> appropriate parts and encoded into the c-line and m-line. For example 
> (leaving out lines that don't change)
> 
>  c=IN IP4 alice.example.com
>  m=message 9 msrp *
>  a=path:msrp://a.example.com:7394/2s93i;tcp
> 
> would become:
> 
>  c=IN IP4 a.example.com
>  m=message 7394 msrp/tcp *
>  a=session:2s93i
> 
> The change would only be made for the destination URL. URLs for any 
> relays would be expressed the same way they are now.
> 
> The advantage of this approach is that it more closely follows the 
> spirit of SDP. This will be easier to understand for people who already 
> know SDP. Existing SDP code could be reused more effectively.
> 
> The disadvantage of the proposed change is, it means the way an MSRP 
> client determines the destination URL would be different depending on 
> whether the URL represented the final destination or a relay. Instead of 
> the current approach of simply copying the path attribute value into the 
> To-Path header in MSRP messages,  a client would copy the path header 
> value if exists, reconstitute the destination URL from the m and c 
> lines, and append the destination URL to the path header value.
> 
> So, what do people think? (I note that we actually did something similar 
> to this before we added the "path" attribute. )

I find the decomposition to be unspeakably ugly. Its bad enough in the 
historic usage where you need to gather things from several places to 
figure out where the RTP is going. But it is MUCH worse when there is a 
familiar format (e.g. a url format) but you have to rip it apart for the 
sake of adhering to the old format that doesn't suit the situation.

The need for two formats - one for the Path and another for the next hop 
is very confusing. Maybe very careful specification could perfume this 
pig so it doesn't smell so bad, but why? Maybe it would be worthwhile if 
it could result in unification with comedia, but I think that is 
generally impossible because we support connection sharing and it doesn't.

     Paul



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


From simple-bounces@ietf.org  Tue Dec  7 15:28:02 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16511;
	Tue, 7 Dec 2004 15:28:02 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbm2x-0005OO-6S; Tue, 07 Dec 2004 15:34:55 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cblnj-0002l7-4m; Tue, 07 Dec 2004 15:19:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CblmS-0001nM-VB
	for simple@megatron.ietf.org; Tue, 07 Dec 2004 15:17:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15454
	for <simple@ietf.org>; Tue, 7 Dec 2004 15:17:51 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cblt5-0005Bv-CW
	for simple@ietf.org; Tue, 07 Dec 2004 15:24:44 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-4.cisco.com with ESMTP; 07 Dec 2004 12:12:33 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB7KCUAJ003302
	for <simple@ietf.org>; Tue, 7 Dec 2004 12:12:30 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-2-132.cisco.com
	[10.86.242.132]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGE28733; Tue, 7 Dec 2004 12:12:29 -0800 (PST)
Message-ID: <41B60EAD.5090504@cisco.com>
Date: Tue, 07 Dec 2004 15:12:29 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simple WG <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665
Content-Transfer-Encoding: 7bit
Subject: [Simple] modeling dispatchers in the data model: a proposal for
	moving forward
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771
Content-Transfer-Encoding: 7bit

We've gotten ourselves stuck lately in a few places in the presence data 
model. In particular, folks have come forward with requirements for 
having multiple services with the same URI. The use cases that have been 
brought forward include:

1. I have a softphone on my PC that is one integrated application, 
available at one AOR with one contact/gruu. I'd like to be able to say 
that I'm available for IM but not available for voice.

2. I have a cell phone that has a common SIP stack by which other 
applications can "register". The sip stack dispatches incoming SIP 
requests to different applications depending on characteristics of the 
request. For example, based on method, codec, media types, SIP 
extensions, URI parameters, etc.


The data model does not, as currently defined, readily handle these 
cases. In my view, the issue of "can we have the same URI for two 
services or not" is a detail around a more general modeling question 
that we have not addressed properly. I think that more general modeling 
question is how we think about dispatchers. Dispatchers are software 
agents which receive service reuqests, but don't directly process them. 
Rather, they dispatch them to another service for processing. By this 
definition, a SIP proxy is a dispatcher. The SIP stack in example 2 
above is also a dispatcher. You could *model* the integrated application 
in example 1 as a dispatcher fronting different services that all happen 
to run in the same process.

A dispatcher is associated with a URI, just like a service as currently 
defined in the model. However, in the model today, there is no way to 
explicitly tell the watcher - "hey, if you invoke this URI, you'll get 
dispatched to 1 of these services depending on some policy". All we can 
do today is have the compositor attempt to compose the component 
services being dispatched to, and thus hide the existence of the 
underlying component services. Where we appear to be running into 
trouble is when we want to expose these component services to the 
watcher, but still convey the fact that there is a dispatcher there - 
usually by trying to publish them all with the same URI.

Since the goal of the data model is to be extremely explicit about what 
presence is, I think the approach we should take here is to be very 
explicit about how we represent dispatchers. As such, I would propose 
the following:

1. Dispatchers be added to the model as a type of service. Like other 
services, they have a <contact> which is the URI you would use to access 
the dispatcher service. They can have characteristics and status. The 
most important characteristic of the dispatcher service is the set of 
services to which the dispatcher will dispatch. This would be enumerated 
explicitly as part of the characteristics of the dispatcher. These 
component services could be specified by URI or by some other identifier 
that serves only to link the component service to the dispatcher.

2. Since dispatchers are services, they can publish their status too. 
This means that, for example, a proxy could PUBLISH (at least 
conceptually) a tuple to a compositor that defines the dispatch 
operation it provides when it receives a request for a particular AOR. 
The current data model is kind of vague about how a compositor would 
know to combine certain services together. The answer is provided by 
this dispatcher. The dispatcher tuple explicitly tells the compositor 
what the "input" URI is, and what the "output" URIs would be.

I'll note tha the reg-event package provides similar information, but 
dispatching is more general than registration.

3. If you have a "dumb" compositor which simply unions together the 
information it gets, when that information contains the component 
services in addition to the dispatcher service, it allows the watcher to 
compose together the component services.

4. A service in the model is most usefully thought of as a "software 
agent". It is a software process running somewhere on the network. Its 
<contact> URI necessarily indicates the address to which a request has 
to be sent in order to be received by that software agent. When an agent 
publishes its own status, it knows its own URI since that is the address 
it is listening at for requests. There needs to be truth in advertising 
for this to work; a software agent representing a service should never 
publish a <contact> that its not actually receiving requests for.



Here are a few examples to make this more concrete.

Example 1: Proxy

Two SIP UAs, on two different PCs, each registering under the same AOR. 
Each UA is a software agent, and provides a service. Each one 
self-publishes (that is, the software agent providing the service is the 
same one generating the PUBLISH request). The pidf document published by 
one of the UA might look something like this:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:jdrosen@cisco.com">
      <tuple id="ub93s3">
        <status>
          <basic>open</basic>
        </status>
        <contact>sip:1.2.3.4</contact>
      </tuple>
    </presence>

Lets say the other UA publishes a similar document, but with a contact 
of 5.6.7.8 and a status of closed.

Lets say the compositor knows about the registrations of those UA. The 
proxy that does the location processing can be modeled as a dispatcher 
service. As a result, the compositor can construct the following 
document which models the proxy:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:jdrosen@cisco.com">
      <tuple id="ub93s9">
        <dispatch-to>
           <uri>sip:1.2.3.4</uri>
           <uri>sip:5.6.7.8</uri>
        </dispatch-to>
        <contact>sip:jdrosen@example.com</contact>
      </tuple>
    </presence>


This says that there is a service at jdrosen@example.com which is a 
dispatcher, dispatching to the two contacts. Using the three documents 
it now has, the compositor can produce several results. One is the 
"transparent" document, which merely combines all of the data:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:jdrosen@cisco.com">
      <tuple id="ub93s9">
        <dispatch-to>
           <uri>sip:1.2.3.4</uri>
           <uri>sip:5.6.7.8</uri>
        </dispatch-to>
        <contact>sip:jdrosen@example.com</contact>
      </tuple>
      <tuple id="ub93s3">
        <status>
          <basic>open</basic>
        </status>
        <contact>sip:1.2.3.4</contact>
      </tuple>
      <tuple id="ub93s4">
        <status>
          <basic>closed</basic>
        </status>
        <contact>sip:5.6.7.8</contact>
      </tuple>
    </presence>


This is a basic "union" operation. Note that the document provides 
sufficient context for a watcher to know how to combine the two 
component services; it knows that they are both reachable through a 
dispatcher. Indeed, in this case, they may ONLY be reachable through the 
dispatcher since the <contact> URIs of the two component services may 
not be directly routable.

Or, instead of being transparent, the compositor can combine the three 
tuples and advertise a single tuple. This single tuple routes to the 
dispatcher, but doesn't make it explicit to the watcher that there is a 
dispatcher; the component services are hidden and the dispatcher is made 
to look like a regular service:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:jdrosen@cisco.com">
      <tuple id="ub93s3">
        <status>
          <basic>open</basic>
        </status>
        <contact>sip:jdrosen@cisco.com</contact>
      </tuple>
    </presence>

What does this mean in terms of the URIs that get put within the 
<contact> elements of each tuple? I think the following can be said:

   a. since each tuple represents a unique service, and since a service 
is associated with a software agent that provides it, there has to, by 
definition, be a unique URI per service.

   b. If two tuples in a document have the same service URI, it means 
that there have been conflicting tuples generated for the same service.

   c. some services may only be reachable through the dispatcher, in 
which case their URIs may not be particularly relevant. They would only 
serve the purposes of correlating the component service to its 
dispatcher. Thus, a gruu would not be needed per se - a contact URI 
would suffice.

   d. If an agent is self-publishing (that is, publishing a tuple about 
itself), the <contact> URI should route to it as far as it knows 
definitively. This would mean that the contact URI of its registration 
or the gruu would do, but not the AOR.

   e. If an agent is third-party publishing, things are more flexible. 
If a UA knows that there are no other UA registered against a particular 
AOR, and if it knows that the proxy itself is not publishing its 
dispatch service, the UA can perform the composition of the two agents 
in the picture (the proxy and the UA), and publish a tuple representing 
the service provided by the *proxy*. In this case, the tuple could have 
the AOR as the <contact>. However, this can be brittle, since the 
ability of the UA to do this is based on it knowing a lot about what 
else is being published. The safest bet is self-publication, since it is 
the approach with the highest likelihood of correctness.

Comments welcome,
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 Dec  7 17:10:42 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05341;
	Tue, 7 Dec 2004 17:10:41 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbneK-0002AY-Ce; Tue, 07 Dec 2004 17:17:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbnMp-0003c7-8Q; Tue, 07 Dec 2004 16:59:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbmsH-0004Z2-Ma
	for simple@megatron.ietf.org; Tue, 07 Dec 2004 16:27:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24596
	for <simple@ietf.org>; Tue, 7 Dec 2004 16:27:55 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbmyi-0007Su-U6
	for simple@ietf.org; Tue, 07 Dec 2004 16:34:37 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-4.cisco.com with ESMTP; 07 Dec 2004 13:27:15 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB7LR6IT025377;
	Tue, 7 Dec 2004 13:27:06 -0800 (PST)
Received: from cisco.com (che-vpn-cluster-1-7.cisco.com [10.86.240.7])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANN50959;
	Tue, 7 Dec 2004 16:27:09 -0500 (EST)
Message-ID: <41B6202D.1010302@cisco.com>
Date: Tue, 07 Dec 2004 16:27:09 -0500
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] modeling dispatchers in the data model: a proposal for
	moving forward
References: <41B60EAD.5090504@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070
Content-Transfer-Encoding: 7bit

Jonathan,

I think perhaps you have found a way out of the dilemma.

I see a couple of issues, perhaps not so big:

- when both the dispatcher and the dispatched services
   are included in the presence document, you depend on
   the contact addresses as the correlating info.

   There is at least a possibility that the contact
   addresses are not all unique. Of course all those
   bound to a single dispatcher must be, but if there
   are two dispatchers and four services, then in
   theory there could be two services with the same
   address (but different network) that are disambiguated
   by the two dispatchers. So the dispatchers have no
   trouble dispatching, but a watcher can't do the
   proper correlation. This may be too far fetched to
   worry about.

   When GRUUs are used, there is some ambiguity about
   whether to publish the gruu or the target of the gruu.
   This can be solved by careful specification.

   You also alude to the need for a correlator other
   than contact, for the case when there really is
   only one contact and dispatch is via private
   mechanisms. That might also be a solution for the
   above problem. Or maybe we never want to use contact
   as the correlator.

- This solution still leaves an OR-OF-ANDs case.
   That is the case when there is indeed just one
   service, but where not all combinations of its
   capabilities are valid. But perhaps this just
   needs to be left to another day. Or maybe this
   can be modeled as a dispatcher to two services
   even though that isn't quite what it is.

Otherwise I think this works for me.

	Paul

Jonathan Rosenberg wrote:
> We've gotten ourselves stuck lately in a few places in the presence data 
> model. In particular, folks have come forward with requirements for 
> having multiple services with the same URI. The use cases that have been 
> brought forward include:
> 
> 1. I have a softphone on my PC that is one integrated application, 
> available at one AOR with one contact/gruu. I'd like to be able to say 
> that I'm available for IM but not available for voice.
> 
> 2. I have a cell phone that has a common SIP stack by which other 
> applications can "register". The sip stack dispatches incoming SIP 
> requests to different applications depending on characteristics of the 
> request. For example, based on method, codec, media types, SIP 
> extensions, URI parameters, etc.
> 
> 
> The data model does not, as currently defined, readily handle these 
> cases. In my view, the issue of "can we have the same URI for two 
> services or not" is a detail around a more general modeling question 
> that we have not addressed properly. I think that more general modeling 
> question is how we think about dispatchers. Dispatchers are software 
> agents which receive service reuqests, but don't directly process them. 
> Rather, they dispatch them to another service for processing. By this 
> definition, a SIP proxy is a dispatcher. The SIP stack in example 2 
> above is also a dispatcher. You could *model* the integrated application 
> in example 1 as a dispatcher fronting different services that all happen 
> to run in the same process.
> 
> A dispatcher is associated with a URI, just like a service as currently 
> defined in the model. However, in the model today, there is no way to 
> explicitly tell the watcher - "hey, if you invoke this URI, you'll get 
> dispatched to 1 of these services depending on some policy". All we can 
> do today is have the compositor attempt to compose the component 
> services being dispatched to, and thus hide the existence of the 
> underlying component services. Where we appear to be running into 
> trouble is when we want to expose these component services to the 
> watcher, but still convey the fact that there is a dispatcher there - 
> usually by trying to publish them all with the same URI.
> 
> Since the goal of the data model is to be extremely explicit about what 
> presence is, I think the approach we should take here is to be very 
> explicit about how we represent dispatchers. As such, I would propose 
> the following:
> 
> 1. Dispatchers be added to the model as a type of service. Like other 
> services, they have a <contact> which is the URI you would use to access 
> the dispatcher service. They can have characteristics and status. The 
> most important characteristic of the dispatcher service is the set of 
> services to which the dispatcher will dispatch. This would be enumerated 
> explicitly as part of the characteristics of the dispatcher. These 
> component services could be specified by URI or by some other identifier 
> that serves only to link the component service to the dispatcher.
> 
> 2. Since dispatchers are services, they can publish their status too. 
> This means that, for example, a proxy could PUBLISH (at least 
> conceptually) a tuple to a compositor that defines the dispatch 
> operation it provides when it receives a request for a particular AOR. 
> The current data model is kind of vague about how a compositor would 
> know to combine certain services together. The answer is provided by 
> this dispatcher. The dispatcher tuple explicitly tells the compositor 
> what the "input" URI is, and what the "output" URIs would be.
> 
> I'll note tha the reg-event package provides similar information, but 
> dispatching is more general than registration.
> 
> 3. If you have a "dumb" compositor which simply unions together the 
> information it gets, when that information contains the component 
> services in addition to the dispatcher service, it allows the watcher to 
> compose together the component services.
> 
> 4. A service in the model is most usefully thought of as a "software 
> agent". It is a software process running somewhere on the network. Its 
> <contact> URI necessarily indicates the address to which a request has 
> to be sent in order to be received by that software agent. When an agent 
> publishes its own status, it knows its own URI since that is the address 
> it is listening at for requests. There needs to be truth in advertising 
> for this to work; a software agent representing a service should never 
> publish a <contact> that its not actually receiving requests for.
> 
> 
> 
> Here are a few examples to make this more concrete.
> 
> Example 1: Proxy
> 
> Two SIP UAs, on two different PCs, each registering under the same AOR. 
> Each UA is a software agent, and provides a service. Each one 
> self-publishes (that is, the software agent providing the service is the 
> same one generating the PUBLISH request). The pidf document published by 
> one of the UA might look something like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:1.2.3.4</contact>
>      </tuple>
>    </presence>
> 
> Lets say the other UA publishes a similar document, but with a contact 
> of 5.6.7.8 and a status of closed.
> 
> Lets say the compositor knows about the registrations of those UA. The 
> proxy that does the location processing can be modeled as a dispatcher 
> service. As a result, the compositor can construct the following 
> document which models the proxy:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s9">
>        <dispatch-to>
>           <uri>sip:1.2.3.4</uri>
>           <uri>sip:5.6.7.8</uri>
>        </dispatch-to>
>        <contact>sip:jdrosen@example.com</contact>
>      </tuple>
>    </presence>
> 
> 
> This says that there is a service at jdrosen@example.com which is a 
> dispatcher, dispatching to the two contacts. Using the three documents 
> it now has, the compositor can produce several results. One is the 
> "transparent" document, which merely combines all of the data:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s9">
>        <dispatch-to>
>           <uri>sip:1.2.3.4</uri>
>           <uri>sip:5.6.7.8</uri>
>        </dispatch-to>
>        <contact>sip:jdrosen@example.com</contact>
>      </tuple>
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:1.2.3.4</contact>
>      </tuple>
>      <tuple id="ub93s4">
>        <status>
>          <basic>closed</basic>
>        </status>
>        <contact>sip:5.6.7.8</contact>
>      </tuple>
>    </presence>
> 
> 
> This is a basic "union" operation. Note that the document provides 
> sufficient context for a watcher to know how to combine the two 
> component services; it knows that they are both reachable through a 
> dispatcher. Indeed, in this case, they may ONLY be reachable through the 
> dispatcher since the <contact> URIs of the two component services may 
> not be directly routable.
> 
> Or, instead of being transparent, the compositor can combine the three 
> tuples and advertise a single tuple. This single tuple routes to the 
> dispatcher, but doesn't make it explicit to the watcher that there is a 
> dispatcher; the component services are hidden and the dispatcher is made 
> to look like a regular service:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:jdrosen@cisco.com</contact>
>      </tuple>
>    </presence>
> 
> What does this mean in terms of the URIs that get put within the 
> <contact> elements of each tuple? I think the following can be said:
> 
>   a. since each tuple represents a unique service, and since a service 
> is associated with a software agent that provides it, there has to, by 
> definition, be a unique URI per service.
> 
>   b. If two tuples in a document have the same service URI, it means 
> that there have been conflicting tuples generated for the same service.
> 
>   c. some services may only be reachable through the dispatcher, in 
> which case their URIs may not be particularly relevant. They would only 
> serve the purposes of correlating the component service to its 
> dispatcher. Thus, a gruu would not be needed per se - a contact URI 
> would suffice.
> 
>   d. If an agent is self-publishing (that is, publishing a tuple about 
> itself), the <contact> URI should route to it as far as it knows 
> definitively. This would mean that the contact URI of its registration 
> or the gruu would do, but not the AOR.
> 
>   e. If an agent is third-party publishing, things are more flexible. If 
> a UA knows that there are no other UA registered against a particular 
> AOR, and if it knows that the proxy itself is not publishing its 
> dispatch service, the UA can perform the composition of the two agents 
> in the picture (the proxy and the UA), and publish a tuple representing 
> the service provided by the *proxy*. In this case, the tuple could have 
> the AOR as the <contact>. However, this can be brittle, since the 
> ability of the UA to do this is based on it knowing a lot about what 
> else is being published. The safest bet is self-publication, since it is 
> the approach with the highest likelihood of correctness.
> 
> Comments welcome,
> Jonathan R.

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


From simple-bounces@ietf.org  Tue Dec  7 18:55:25 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16543;
	Tue, 7 Dec 2004 18:55:25 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbpHh-0004qi-AV; Tue, 07 Dec 2004 19:02:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbown-000521-NU; Tue, 07 Dec 2004 18:40:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbode-0006BF-Pb; Tue, 07 Dec 2004 18:20:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13861;
	Tue, 7 Dec 2004 18:20:55 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbokJ-0004Az-6i; Tue, 07 Dec 2004 18:27:51 -0500
Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB7NKrhB013262
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 7 Dec 2004 17:20:55 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Simple WG <simple@ietf.org>, mmusic@ietf.org
From: Ben Campbell <ben@nostrum.com>
Date: Tue, 7 Dec 2004 17:20:47 -0600
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Subject: [Simple] MSRP: SDP usage concern
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit

I sent the attached to the SIMPLE list last week. I am reposting it to  
both the SIMPLE and MMUSIC lists, as the discussion is of interest to  
both groups. If you already responded to this on the SIMPLE list or in  
private, it would be helpful if you can re-post your response to this  
thread, so everyone sees the whole discussion.

Thanks!

Ben.

------------------------------------------------------------------------ 
----------------------------------------


In the DC meeting, we discussed that MSRP's SDP usage should be  
reviewed in MMUSIC, or at least by people who are more expert in SDP.   
Colin Perkins and Joerg Ott looked at this, and suggested a change.  
(Many thanks to them for taking the time, and I hope they will jump in  
and correct me if I mischaracterize anything.)

The upshot of the proposal is that the fact that MSRP ignores the  
address in the sdp c-line, and the port and proto fields in the m-line.  
Instead, MSRP gets all of this from the first URL in the path a-line  
attribute. This deviates from the traditional usage in SDP, and causes  
confusion.

The proposed change is that the destination URL be broken into the  
appropriate parts and encoded into the c-line and m-line. For example  
(leaving out lines that don't change)

  c=IN IP4 alice.example.com
  m=message 9 msrp *
  a=path:msrp://a.example.com:7394/2s93i;tcp

would become:

  c=IN IP4 a.example.com
  m=message 7394 msrp/tcp *
  a=session:2s93i

The change would only be made for the destination URL. URLs for any  
relays would be expressed the same way they are now.

The advantage of this approach is that it more closely follows the  
spirit of SDP. This will be easier to understand for people who already  
know SDP. Existing SDP code could be reused more effectively.

The disadvantage of the proposed change is, it means the way an MSRP  
client determines the destination URL would be different depending on  
whether the URL represented the final destination or a relay. Instead  
of the current approach of simply copying the path attribute value into  
the To-Path header in MSRP messages,  a client would copy the path  
header value if exists, reconstitute the destination URL from the m and  
c lines, and append the destination URL to the path header value.

So, what do people think? (I note that we actually did something  
similar to this before we added the "path" attribute. )


Thanks!

Ben.



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


From simple-bounces@ietf.org  Tue Dec  7 23:18:11 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11318;
	Tue, 7 Dec 2004 23:18:11 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbtO0-0002L3-VS; Tue, 07 Dec 2004 23:25:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbtF3-0003oV-25; Tue, 07 Dec 2004 23:15:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbtAV-0002YH-OU
	for simple@megatron.ietf.org; Tue, 07 Dec 2004 23:11:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10872
	for <simple@ietf.org>; Tue, 7 Dec 2004 23:11:09 -0500 (EST)
Received: from jalapeno.cc.columbia.edu ([128.59.206.19] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbtHC-0002B6-SP
	for simple@ietf.org; Tue, 07 Dec 2004 23:18:07 -0500
Received: from [192.168.0.31] (pool-141-153-176-26.mad.east.verizon.net
	[141.153.176.26]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	iB84AsRs006210
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 7 Dec 2004 23:11:08 -0500 (EST)
Message-ID: <41B67ECE.4000300@cs.columbia.edu>
Date: Tue, 07 Dec 2004 23:10:54 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for
	moving forward
References: <41B60EAD.5090504@cisco.com>
In-Reply-To: <41B60EAD.5090504@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.206.19
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b
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
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4
Content-Transfer-Encoding: 7bit

I think this does provide more explicit description of interesting, 
SIP-oriented subcases of the problem, albeit at the cost of increased 
complexity.

With this approach, I see no need to use URIs as tuple identification, 
i.e., forcing the merging of tuples that have different tuple id's (your 
ub93s*), but the same contact URI. The contact URI are needed only as 
correlators that allow the watcher to tell that a particular dispatcher 
and a set of service tuples are related.

To avoid the need for inventing non-reachable URIs (which seem like a 
bad idea), one could reverse this and simply have the individual 
services indicate their "master" URI. (I'm avoiding the AOR term to be 
less SIP-specific.), as in

  <tuple id="ub93s3">
    <i-belong-to>sip:jdrosen@example.com</i-belong-to>
        <status>
          <basic>open</basic>
        </status>
        <contact></contact>
      </tuple>

Here, the contact can be empty or not, depending on whether the contact 
URI is meaningful or not.

If there is no way to contact that service (SIP or non-SIP) except by 
describing the service to the dispatcher, there's no need to include the 
contact-URIs or the <contact> element.

The dispatched services will always know their master by his voice/URI.

My concern continues to be that any rule has to work with all kinds of 
URIs, including schemes the composer knows nothing about and schemes 
where non-URI components are needed to describe the service. (As 
discussed, these qualifiers would be labeled as mandatory-to-understand 
elements, as described in Section 4.3.3 of the PIDF draft.)

I believe with this modification, a purely additive composer will do no 
harm, but watchers will know exactly what's going on. (I believe this 
will also solve the or-of-and problem, in that it is simply a special 
catch of the dispatch problem.)

Henning


Jonathan Rosenberg wrote:
> We've gotten ourselves stuck lately in a few places in the presence data 
> model. In particular, folks have come forward with requirements for 
> having multiple services with the same URI. The use cases that have been 
> brought forward include:
> 
> 1. I have a softphone on my PC that is one integrated application, 
> available at one AOR with one contact/gruu. I'd like to be able to say 
> that I'm available for IM but not available for voice.
> 
> 2. I have a cell phone that has a common SIP stack by which other 
> applications can "register". The sip stack dispatches incoming SIP 
> requests to different applications depending on characteristics of the 
> request. For example, based on method, codec, media types, SIP 
> extensions, URI parameters, etc.
> 
> 
> The data model does not, as currently defined, readily handle these 
> cases. In my view, the issue of "can we have the same URI for two 
> services or not" is a detail around a more general modeling question 
> that we have not addressed properly. I think that more general modeling 
> question is how we think about dispatchers. Dispatchers are software 
> agents which receive service reuqests, but don't directly process them. 
> Rather, they dispatch them to another service for processing. By this 
> definition, a SIP proxy is a dispatcher. The SIP stack in example 2 
> above is also a dispatcher. You could *model* the integrated application 
> in example 1 as a dispatcher fronting different services that all happen 
> to run in the same process.
> 
> A dispatcher is associated with a URI, just like a service as currently 
> defined in the model. However, in the model today, there is no way to 
> explicitly tell the watcher - "hey, if you invoke this URI, you'll get 
> dispatched to 1 of these services depending on some policy". All we can 
> do today is have the compositor attempt to compose the component 
> services being dispatched to, and thus hide the existence of the 
> underlying component services. Where we appear to be running into 
> trouble is when we want to expose these component services to the 
> watcher, but still convey the fact that there is a dispatcher there - 
> usually by trying to publish them all with the same URI.
> 
> Since the goal of the data model is to be extremely explicit about what 
> presence is, I think the approach we should take here is to be very 
> explicit about how we represent dispatchers. As such, I would propose 
> the following:
> 
> 1. Dispatchers be added to the model as a type of service. Like other 
> services, they have a <contact> which is the URI you would use to access 
> the dispatcher service. They can have characteristics and status. The 
> most important characteristic of the dispatcher service is the set of 
> services to which the dispatcher will dispatch. This would be enumerated 
> explicitly as part of the characteristics of the dispatcher. These 
> component services could be specified by URI or by some other identifier 
> that serves only to link the component service to the dispatcher.
> 
> 2. Since dispatchers are services, they can publish their status too. 
> This means that, for example, a proxy could PUBLISH (at least 
> conceptually) a tuple to a compositor that defines the dispatch 
> operation it provides when it receives a request for a particular AOR. 
> The current data model is kind of vague about how a compositor would 
> know to combine certain services together. The answer is provided by 
> this dispatcher. The dispatcher tuple explicitly tells the compositor 
> what the "input" URI is, and what the "output" URIs would be.
> 
> I'll note tha the reg-event package provides similar information, but 
> dispatching is more general than registration.
> 
> 3. If you have a "dumb" compositor which simply unions together the 
> information it gets, when that information contains the component 
> services in addition to the dispatcher service, it allows the watcher to 
> compose together the component services.
> 
> 4. A service in the model is most usefully thought of as a "software 
> agent". It is a software process running somewhere on the network. Its 
> <contact> URI necessarily indicates the address to which a request has 
> to be sent in order to be received by that software agent. When an agent 
> publishes its own status, it knows its own URI since that is the address 
> it is listening at for requests. There needs to be truth in advertising 
> for this to work; a software agent representing a service should never 
> publish a <contact> that its not actually receiving requests for.
> 
> 
> 
> Here are a few examples to make this more concrete.
> 
> Example 1: Proxy
> 
> Two SIP UAs, on two different PCs, each registering under the same AOR. 
> Each UA is a software agent, and provides a service. Each one 
> self-publishes (that is, the software agent providing the service is the 
> same one generating the PUBLISH request). The pidf document published by 
> one of the UA might look something like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:1.2.3.4</contact>
>      </tuple>
>    </presence>
> 
> Lets say the other UA publishes a similar document, but with a contact 
> of 5.6.7.8 and a status of closed.
> 
> Lets say the compositor knows about the registrations of those UA. The 
> proxy that does the location processing can be modeled as a dispatcher 
> service. As a result, the compositor can construct the following 
> document which models the proxy:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s9">
>        <dispatch-to>
>           <uri>sip:1.2.3.4</uri>
>           <uri>sip:5.6.7.8</uri>
>        </dispatch-to>
>        <contact>sip:jdrosen@example.com</contact>
>      </tuple>
>    </presence>
> 
> 
> This says that there is a service at jdrosen@example.com which is a 
> dispatcher, dispatching to the two contacts. Using the three documents 
> it now has, the compositor can produce several results. One is the 
> "transparent" document, which merely combines all of the data:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s9">
>        <dispatch-to>
>           <uri>sip:1.2.3.4</uri>
>           <uri>sip:5.6.7.8</uri>
>        </dispatch-to>
>        <contact>sip:jdrosen@example.com</contact>
>      </tuple>
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:1.2.3.4</contact>
>      </tuple>
>      <tuple id="ub93s4">
>        <status>
>          <basic>closed</basic>
>        </status>
>        <contact>sip:5.6.7.8</contact>
>      </tuple>
>    </presence>
> 
> 
> This is a basic "union" operation. Note that the document provides 
> sufficient context for a watcher to know how to combine the two 
> component services; it knows that they are both reachable through a 
> dispatcher. Indeed, in this case, they may ONLY be reachable through the 
> dispatcher since the <contact> URIs of the two component services may 
> not be directly routable.
> 
> Or, instead of being transparent, the compositor can combine the three 
> tuples and advertise a single tuple. This single tuple routes to the 
> dispatcher, but doesn't make it explicit to the watcher that there is a 
> dispatcher; the component services are hidden and the dispatcher is made 
> to look like a regular service:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:jdrosen@cisco.com</contact>
>      </tuple>
>    </presence>
> 
> What does this mean in terms of the URIs that get put within the 
> <contact> elements of each tuple? I think the following can be said:
> 
>   a. since each tuple represents a unique service, and since a service 
> is associated with a software agent that provides it, there has to, by 
> definition, be a unique URI per service.
> 
>   b. If two tuples in a document have the same service URI, it means 
> that there have been conflicting tuples generated for the same service.
> 
>   c. some services may only be reachable through the dispatcher, in 
> which case their URIs may not be particularly relevant. They would only 
> serve the purposes of correlating the component service to its 
> dispatcher. Thus, a gruu would not be needed per se - a contact URI 
> would suffice.
> 
>   d. If an agent is self-publishing (that is, publishing a tuple about 
> itself), the <contact> URI should route to it as far as it knows 
> definitively. This would mean that the contact URI of its registration 
> or the gruu would do, but not the AOR.
> 
>   e. If an agent is third-party publishing, things are more flexible. If 
> a UA knows that there are no other UA registered against a particular 
> AOR, and if it knows that the proxy itself is not publishing its 
> dispatch service, the UA can perform the composition of the two agents 
> in the picture (the proxy and the UA), and publish a tuple representing 
> the service provided by the *proxy*. In this case, the tuple could have 
> the AOR as the <contact>. However, this can be brittle, since the 
> ability of the UA to do this is based on it knowing a lot about what 
> else is being published. The safest bet is self-publication, since it is 
> the approach with the highest likelihood of correctness.
> 
> Comments welcome,
> Jonathan R.


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


From simple-bounces@ietf.org  Thu Dec  9 00:57:55 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07950;
	Thu, 9 Dec 2004 00:57:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcHQK-000592-Bb; Thu, 09 Dec 2004 01:05:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcHIR-0002KN-KH; Thu, 09 Dec 2004 00:56:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcHAP-000135-2z
	for simple@megatron.ietf.org; Thu, 09 Dec 2004 00:48:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06927
	for <simple@ietf.org>; Thu, 9 Dec 2004 00:48:37 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcHHH-0004ul-1S
	for simple@ietf.org; Thu, 09 Dec 2004 00:55:50 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 08 Dec 2004 21:50:53 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB95m4m4004887;
	Wed, 8 Dec 2004 21:48:04 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-2-180.cisco.com
	[10.86.242.180]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGF35714; Wed, 8 Dec 2004 21:48:03 -0800 (PST)
Message-ID: <41B7E711.8030800@cisco.com>
Date: Thu, 09 Dec 2004 00:48:01 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MARJOU Xavier RD-MAPS-LAN <xavier.marjou@francetelecom.com>
References: <B30D6148F304A743A53B9B44751CDB9A025577F8@FTRDMEL2.rd.francetelecom.fr>
In-Reply-To: <B30D6148F304A743A53B9B44751CDB9A025577F8@FTRDMEL2.rd.francetelecom.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org
Subject: [Simple] Re: Question concerning draft-ietf-simple-presence-rules-01
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit

You can assign a set of transformations to apply to everyone, and you 
can assign a set of transformations to apply to a given identity. 
However, the transformations you apply to everyone would also apply to 
that user with the given identity.

-Jonathan R.

MARJOU Xavier RD-MAPS-LAN wrote:

> Hi,
> 
> I have a use-case were I want to make some transformations for a given
> identity (eg: good buddy) and others transformations for all other
> possible identities (eg: rest of the world).
>>From draft-ietf-geopriv-common-policy-03, I understand that it is not
> possible to implement it? Am I correct?
> 
> Thanks,
> Xavier
> 

-- 
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  Thu Dec  9 17:26:04 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21134;
	Thu, 9 Dec 2004 17:26:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcWqi-0003rv-BP; Thu, 09 Dec 2004 17:33:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcWMw-00011H-PG; Thu, 09 Dec 2004 17:02:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcWAU-0003e5-U8; Thu, 09 Dec 2004 16:49:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14573;
	Thu, 9 Dec 2004 16:49:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcWHY-00020S-5Y; Thu, 09 Dec 2004 16:57:04 -0500
Received: from apache by megatron.ietf.org with local (Exim 4.32)
	id 1CcVme-0004tt-S2; Thu, 09 Dec 2004 16:25:08 -0500
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1CcVme-0004tt-S2@megatron.ietf.org>
Date: Thu, 09 Dec 2004 16:25:08 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: simple@ietf.org
Subject: [Simple] Last Call: 'An Extensible Markup Language (XML)
 Configuration Access 
 Protocol (XCAP) Usage for Manipulating Presence Document Contents' to 
 Proposed Standard 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

The IESG has received a request from the SIP for Instant Messaging and 
Presence Leveraging Extensions WG to consider the following document:

- 'An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 
   Usage for Manipulating Presence Document Contents '
   <draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt> as a Proposed
   Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-28.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usa
ge-02.txt


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


From simple-bounces@ietf.org  Thu Dec  9 17:27:07 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21389;
	Thu, 9 Dec 2004 17:27:06 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcWrj-0003xA-7D; Thu, 09 Dec 2004 17:34:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcWN0-00012Q-PS; Thu, 09 Dec 2004 17:02:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcWBs-0004FV-DI; Thu, 09 Dec 2004 16:51:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14644;
	Thu, 9 Dec 2004 16:51:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcWIw-00022Q-9N; Thu, 09 Dec 2004 16:58:30 -0500
Received: from apache by megatron.ietf.org with local (Exim 4.32)
	id 1CcVo8-0005tm-U3; Thu, 09 Dec 2004 16:26:40 -0500
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1CcVo8-0005tm-U3@megatron.ietf.org>
Date: Thu, 09 Dec 2004 16:26:40 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: simple@ietf.org
Subject: [Simple] Last Call: 'The Extensible Markup Language (XML)
 Configuration Access Protocol (XCAP)' to Proposed Standard 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

The IESG has received a request from the SIP for Instant Messaging and 
Presence Leveraging Extensions WG to consider the following document:

- 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) '
   <draft-ietf-simple-xcap-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-28.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt


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


From njovetpnlzho@msn.com  Fri Dec 10 16:36:34 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29292;
	Fri, 10 Dec 2004 16:36:34 -0500 (EST)
Received: from lsanca1-wbar6-4-11-026-179.lsanca1.dsl-verizon.net ([4.11.26.179])
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1CcsYX-0000sl-A9; Fri, 10 Dec 2004 16:44:05 -0500
Received: from dinghy [193.57.200.0] (helo=duration.nauseate.dearriba.com)
	by smtp2.cistron.nl with esmtp (salesgirl 3.35 #1 (radical))
	id 398LFL-0095PT-50
Message-ID: <28251773144732.R37438@age.noc.admissible.gr>
Sender: freeradius-devel-njovetpnlzho@msn.com
X-Mailman-Version: 2.0.1
Date: Sat, 11 Dec 2004 17:32:17 +0500
From: "Avery Padgett" <njovetpnlzho@msn.com>
To: simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org,
        simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org,
        sip-request@ietf.org, sip-security@ietf.org
Subject:  Viicodin and Hydroc0done Heree oRR
X-Spam-Score: 8.2 (++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


Our very besstt price of medss:

Pain Relief (from $99)
(Viicodin, Hydrocodoone, Valliium)

Men's Pillls (from $140)
(Viiagra, Leviitra)

Weight Losss (from $140)
(Phentermiine, Xeniical)


You Can't find this 0ffers available anywhere.
Visit Us T0day!

http://www.nosleep4me.com/2/vicodin.php?wid=200007








This is 1 -time mailing. N0-re m0val are re'qui-red
p8RKRKqtccwoA7w8RTuGBvQRSER8gTvoYtkJj6FRzwIv4w64


From simple-bounces@ietf.org  Fri Dec 10 16:52:12 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01506;
	Fri, 10 Dec 2004 16:52:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ccsnh-0001NQ-Pg; Fri, 10 Dec 2004 16:59:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcsZM-0004l5-Ne; Fri, 10 Dec 2004 16:44:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcsVu-0003UZ-Mn; Fri, 10 Dec 2004 16:41:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00688;
	Fri, 10 Dec 2004 16:41:20 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcsdA-00016w-QU; Fri, 10 Dec 2004 16:48:53 -0500
Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBALfDBN042881
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 10 Dec 2004 15:41:14 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] MSRP: SDP usage concern
Date: Fri, 10 Dec 2004 15:41:12 -0600
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>, mmusic@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: 7bit

I really need to get closure on this, so I'd appreciate people agreeing  
or disagreeing.

I have had off-list correspondence indicating both positions. In  
summary:

In favor of the change, I had a comment to the effect that changing SDP  
semantics to ignore the C line and the port field on the M line really  
changes it to something that is no longer SDP, and that such deviations  
are in general bad for interop.

In favor of leaving things as currently specified, I had two comments  
that decomposing URLs into the C and M lines is ugly, and that having a  
different mechanism to communicate endpoint addresses vs relay  
addresses is really ugly.

So, do people agree with one or the other position? Something  
completely different? (Hopefully the people who sent off-list  
correspondence will reply on-list if they think I mischaracterized  
either position. Actually, I hope they will repost on-list even if they  
like my summaries)

I have so far avoided interjecting my personal opinion so that I could  
do a fair summary. But, I actually tend to agree with the  
leave-things-as-specified position.

While I am sensitive to the issue of deviating from the spirit of SDP,  
I don't really buy the interoperability argument. The currently defined  
usage _does_ put "msrp" in the M line--so only consumers that  
understand what that means will be able to act on it. I assume that any  
endpoint that understands what "msrp" means will also understand how to  
use the "path" attribute.

The place that interoperability might suffer is if any non-endpoint  
needs to interpret things--which is generally not a goal. I guess can  
also see debug or monitoring tools who don't know about MSRP getting  
things wrong.

My biggest technical objection is that using a different mechanism for  
determining where to connect depending on whether you are connecting  
peer to peer or through a relay, increases the chances of implementors  
getting things wrong. And I cannot personally think of a way to handle  
relay addresses that is more in the spirit of SDP than what we  
currently have.

But in any case, I will be happy to document consensus, even if it  
disagrees with my position. But we need to close on it asap.

Thanks!

Ben.

On Dec 7, 2004, at 5:20 PM, Ben Campbell wrote:

> I sent the attached to the SIMPLE list last week. I am reposting it to  
> both the SIMPLE and MMUSIC lists, as the discussion is of interest to  
> both groups. If you already responded to this on the SIMPLE list or in  
> private, it would be helpful if you can re-post your response to this  
> thread, so everyone sees the whole discussion.
>
> Thanks!
>
> Ben.
>
> ----------------------------------------------------------------------- 
> -----------------------------------------
>
>
> In the DC meeting, we discussed that MSRP's SDP usage should be  
> reviewed in MMUSIC, or at least by people who are more expert in SDP.   
> Colin Perkins and Joerg Ott looked at this, and suggested a change.  
> (Many thanks to them for taking the time, and I hope they will jump in  
> and correct me if I mischaracterize anything.)
>
> The upshot of the proposal is that the fact that MSRP ignores the  
> address in the sdp c-line, and the port and proto fields in the  
> m-line. Instead, MSRP gets all of this from the first URL in the path  
> a-line attribute. This deviates from the traditional usage in SDP, and  
> causes confusion.
>
> The proposed change is that the destination URL be broken into the  
> appropriate parts and encoded into the c-line and m-line. For example  
> (leaving out lines that don't change)
>
>  c=IN IP4 alice.example.com
>  m=message 9 msrp *
>  a=path:msrp://a.example.com:7394/2s93i;tcp
>
> would become:
>
>  c=IN IP4 a.example.com
>  m=message 7394 msrp/tcp *
>  a=session:2s93i
>
> The change would only be made for the destination URL. URLs for any  
> relays would be expressed the same way they are now.
>
> The advantage of this approach is that it more closely follows the  
> spirit of SDP. This will be easier to understand for people who  
> already know SDP. Existing SDP code could be reused more effectively.
>
> The disadvantage of the proposed change is, it means the way an MSRP  
> client determines the destination URL would be different depending on  
> whether the URL represented the final destination or a relay. Instead  
> of the current approach of simply copying the path attribute value  
> into the To-Path header in MSRP messages,  a client would copy the  
> path header value if exists, reconstitute the destination URL from the  
> m and c lines, and append the destination URL to the path header  
> value.
>
> So, what do people think? (I note that we actually did something  
> similar to this before we added the "path" attribute. )
>
>
> Thanks!
>
> Ben.
>
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>


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


From simple-bounces@ietf.org  Fri Dec 10 17:41:49 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04838;
	Fri, 10 Dec 2004 17:41:49 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CctZj-0002MV-4R; Fri, 10 Dec 2004 17:49:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CctMg-0008IB-CW; Fri, 10 Dec 2004 17:35:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CctIe-0007SQ-3c; Fri, 10 Dec 2004 17:31:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04169;
	Fri, 10 Dec 2004 17:31:41 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CctPu-0002B9-Vz; Fri, 10 Dec 2004 17:39:15 -0500
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 10 Dec 2004 17:31:14 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBAMVAQ6027257; 
	Fri, 10 Dec 2004 17:31:10 -0500 (EST)
Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id ANQ09484; Fri, 10 Dec 2004 17:31:07 -0500 (EST)
Message-ID: <41BA23AB.7010106@cisco.com>
Date: Fri, 10 Dec 2004 17:31:07 -0500
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] MSRP: SDP usage concern
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>
	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>, mmusic@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: 7bit

Ben,

I agree with what you say below, and have no more to add now.

	Paul

Ben Campbell wrote:
> I really need to get closure on this, so I'd appreciate people agreeing  
> or disagreeing.
> 
> I have had off-list correspondence indicating both positions. In  summary:
> 
> In favor of the change, I had a comment to the effect that changing SDP  
> semantics to ignore the C line and the port field on the M line really  
> changes it to something that is no longer SDP, and that such deviations  
> are in general bad for interop.
> 
> In favor of leaving things as currently specified, I had two comments  
> that decomposing URLs into the C and M lines is ugly, and that having a  
> different mechanism to communicate endpoint addresses vs relay  
> addresses is really ugly.
> 
> So, do people agree with one or the other position? Something  
> completely different? (Hopefully the people who sent off-list  
> correspondence will reply on-list if they think I mischaracterized  
> either position. Actually, I hope they will repost on-list even if they  
> like my summaries)
> 
> I have so far avoided interjecting my personal opinion so that I could  
> do a fair summary. But, I actually tend to agree with the  
> leave-things-as-specified position.
> 
> While I am sensitive to the issue of deviating from the spirit of SDP,  
> I don't really buy the interoperability argument. The currently defined  
> usage _does_ put "msrp" in the M line--so only consumers that  
> understand what that means will be able to act on it. I assume that any  
> endpoint that understands what "msrp" means will also understand how to  
> use the "path" attribute.
> 
> The place that interoperability might suffer is if any non-endpoint  
> needs to interpret things--which is generally not a goal. I guess can  
> also see debug or monitoring tools who don't know about MSRP getting  
> things wrong.
> 
> My biggest technical objection is that using a different mechanism for  
> determining where to connect depending on whether you are connecting  
> peer to peer or through a relay, increases the chances of implementors  
> getting things wrong. And I cannot personally think of a way to handle  
> relay addresses that is more in the spirit of SDP than what we  
> currently have.
> 
> But in any case, I will be happy to document consensus, even if it  
> disagrees with my position. But we need to close on it asap.
> 
> Thanks!
> 
> Ben.
> 
> On Dec 7, 2004, at 5:20 PM, Ben Campbell wrote:
> 
>> I sent the attached to the SIMPLE list last week. I am reposting it 
>> to  both the SIMPLE and MMUSIC lists, as the discussion is of interest 
>> to  both groups. If you already responded to this on the SIMPLE list 
>> or in  private, it would be helpful if you can re-post your response 
>> to this  thread, so everyone sees the whole discussion.
>>
>> Thanks!
>>
>> Ben.
>>
>> ----------------------------------------------------------------------- 
>> -----------------------------------------
>>
>>
>> In the DC meeting, we discussed that MSRP's SDP usage should be  
>> reviewed in MMUSIC, or at least by people who are more expert in 
>> SDP.   Colin Perkins and Joerg Ott looked at this, and suggested a 
>> change.  (Many thanks to them for taking the time, and I hope they 
>> will jump in  and correct me if I mischaracterize anything.)
>>
>> The upshot of the proposal is that the fact that MSRP ignores the  
>> address in the sdp c-line, and the port and proto fields in the  
>> m-line. Instead, MSRP gets all of this from the first URL in the path  
>> a-line attribute. This deviates from the traditional usage in SDP, 
>> and  causes confusion.
>>
>> The proposed change is that the destination URL be broken into the  
>> appropriate parts and encoded into the c-line and m-line. For example  
>> (leaving out lines that don't change)
>>
>>  c=IN IP4 alice.example.com
>>  m=message 9 msrp *
>>  a=path:msrp://a.example.com:7394/2s93i;tcp
>>
>> would become:
>>
>>  c=IN IP4 a.example.com
>>  m=message 7394 msrp/tcp *
>>  a=session:2s93i
>>
>> The change would only be made for the destination URL. URLs for any  
>> relays would be expressed the same way they are now.
>>
>> The advantage of this approach is that it more closely follows the  
>> spirit of SDP. This will be easier to understand for people who  
>> already know SDP. Existing SDP code could be reused more effectively.
>>
>> The disadvantage of the proposed change is, it means the way an MSRP  
>> client determines the destination URL would be different depending on  
>> whether the URL represented the final destination or a relay. Instead  
>> of the current approach of simply copying the path attribute value  
>> into the To-Path header in MSRP messages,  a client would copy the  
>> path header value if exists, reconstitute the destination URL from 
>> the  m and c lines, and append the destination URL to the path header  
>> value.
>>
>> So, what do people think? (I note that we actually did something  
>> similar to this before we added the "path" attribute. )
>>
>>
>> Thanks!
>>
>> Ben.
>>
>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>>
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

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


From simple-bounces@ietf.org  Sun Dec 12 01:36:43 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20274;
	Sun, 12 Dec 2004 01:36:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdNT5-0003ps-Hh; Sun, 12 Dec 2004 01:44:32 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdNIg-0005Ty-JE; Sun, 12 Dec 2004 01:33:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdNGY-0005Ci-Sg; Sun, 12 Dec 2004 01:31:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20152;
	Sun, 12 Dec 2004 01:31:34 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdNO5-0003lf-3k; Sun, 12 Dec 2004 01:39:23 -0500
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-2.cisco.com with ESMTP; 12 Dec 2004 01:31:02 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBC6Ux9E020714; 
	Sun, 12 Dec 2004 01:30:59 -0500 (EST)
Received: from cisco.com (che-vpn-cluster-2-34.cisco.com [10.86.242.34])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANQ43697;
	Sun, 12 Dec 2004 01:30:58 -0500 (EST)
Message-ID: <41BBE5A2.4080208@cisco.com>
Date: Sun, 12 Dec 2004 01:30:58 -0500
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: Colin Perkins <csp@csperkins.org>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
	<6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>, mmusic@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit



Colin Perkins wrote:
> 
> Decomposing the URL into the "c=" and "m=" lines is very ugly. 
> Unfortunately, that ugliness is required if you want to use SDP. This is 
> why the SDPng work was started, to try to move to something less 
> horrible...

You state that as if it was a hard and fast written law. Is it?

It was one thing to decompose these parts of the communication address 
one time for RTP. But there was no URL for that. Now times have moved 
on, and URLs are common and useful, and they don't fit so well into this 
paradigm. Something has to adapt, but why aren't we free to have an open 
mind about where the adaptation is applied?

	Paul

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


From simple-bounces@ietf.org  Sun Dec 12 06:04:55 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18903;
	Sun, 12 Dec 2004 06:04:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdRei-0004SZ-Mx; Sun, 12 Dec 2004 06:12:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdRW0-0004xQ-ON; Sun, 12 Dec 2004 06:03:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdRSg-0003jB-0z; Sun, 12 Dec 2004 06:00:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18782;
	Sun, 12 Dec 2004 06:00:19 -0500 (EST)
Received: from mgw-x2.nokia.com ([131.228.20.22])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdRaG-0004Os-B0; Sun, 12 Dec 2004 06:08:12 -0500
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBCB0BF20435; Sun, 12 Dec 2004 13:00:12 +0200 (EET)
X-Scanned: Sun, 12 Dec 2004 12:59:28 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBCAxShP005775;
	Sun, 12 Dec 2004 12:59:28 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks004.ntc.nokia.com 00sn8Jvn; Sun, 12 Dec 2004 12:59:25 EET
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBCAxPS25557; Sun, 12 Dec 2004 12:59:25 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh002.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Sun, 12 Dec 2004 12:59:25 +0200
Message-ID: <41BC248D.4030906@nokia.com>
Date: Sun, 12 Dec 2004 12:59:25 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] MSRP: SDP usage concern
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>
	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
In-Reply-To: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Dec 2004 10:59:25.0531 (UTC)
	FILETIME=[A4C46AB0:01C4E039]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>, mmusic@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Content-Transfer-Encoding: 7bit

I also agree with Ben here. I don't see interoperability problems, since 
MSRP implementations will need to add extra support for SDP.

I also think SDP is requiring a general mechanism to be able to indicate 
a URI as a connection address, rather than the traditional IP address + 
port number... but that is another story.

Let's keep the SDP usage in MSRP as it is now.

- Miguel

Ben Campbell wrote:

> I really need to get closure on this, so I'd appreciate people agreeing  
> or disagreeing.
> 
> I have had off-list correspondence indicating both positions. In  summary:
> 
> In favor of the change, I had a comment to the effect that changing SDP  
> semantics to ignore the C line and the port field on the M line really  
> changes it to something that is no longer SDP, and that such deviations  
> are in general bad for interop.
> 
> In favor of leaving things as currently specified, I had two comments  
> that decomposing URLs into the C and M lines is ugly, and that having a  
> different mechanism to communicate endpoint addresses vs relay  
> addresses is really ugly.
> 
> So, do people agree with one or the other position? Something  
> completely different? (Hopefully the people who sent off-list  
> correspondence will reply on-list if they think I mischaracterized  
> either position. Actually, I hope they will repost on-list even if they  
> like my summaries)
> 
> I have so far avoided interjecting my personal opinion so that I could  
> do a fair summary. But, I actually tend to agree with the  
> leave-things-as-specified position.
> 
> While I am sensitive to the issue of deviating from the spirit of SDP,  
> I don't really buy the interoperability argument. The currently defined  
> usage _does_ put "msrp" in the M line--so only consumers that  
> understand what that means will be able to act on it. I assume that any  
> endpoint that understands what "msrp" means will also understand how to  
> use the "path" attribute.
> 
> The place that interoperability might suffer is if any non-endpoint  
> needs to interpret things--which is generally not a goal. I guess can  
> also see debug or monitoring tools who don't know about MSRP getting  
> things wrong.
> 
> My biggest technical objection is that using a different mechanism for  
> determining where to connect depending on whether you are connecting  
> peer to peer or through a relay, increases the chances of implementors  
> getting things wrong. And I cannot personally think of a way to handle  
> relay addresses that is more in the spirit of SDP than what we  
> currently have.
> 
> But in any case, I will be happy to document consensus, even if it  
> disagrees with my position. But we need to close on it asap.
> 
> Thanks!
> 
> Ben.
> 
> On Dec 7, 2004, at 5:20 PM, Ben Campbell wrote:
> 
>> I sent the attached to the SIMPLE list last week. I am reposting it 
>> to  both the SIMPLE and MMUSIC lists, as the discussion is of interest 
>> to  both groups. If you already responded to this on the SIMPLE list 
>> or in  private, it would be helpful if you can re-post your response 
>> to this  thread, so everyone sees the whole discussion.
>>
>> Thanks!
>>
>> Ben.
>>
>> ----------------------------------------------------------------------- 
>> -----------------------------------------
>>
>>
>> In the DC meeting, we discussed that MSRP's SDP usage should be  
>> reviewed in MMUSIC, or at least by people who are more expert in 
>> SDP.   Colin Perkins and Joerg Ott looked at this, and suggested a 
>> change.  (Many thanks to them for taking the time, and I hope they 
>> will jump in  and correct me if I mischaracterize anything.)
>>
>> The upshot of the proposal is that the fact that MSRP ignores the  
>> address in the sdp c-line, and the port and proto fields in the  
>> m-line. Instead, MSRP gets all of this from the first URL in the path  
>> a-line attribute. This deviates from the traditional usage in SDP, 
>> and  causes confusion.
>>
>> The proposed change is that the destination URL be broken into the  
>> appropriate parts and encoded into the c-line and m-line. For example  
>> (leaving out lines that don't change)
>>
>>  c=IN IP4 alice.example.com
>>  m=message 9 msrp *
>>  a=path:msrp://a.example.com:7394/2s93i;tcp
>>
>> would become:
>>
>>  c=IN IP4 a.example.com
>>  m=message 7394 msrp/tcp *
>>  a=session:2s93i
>>
>> The change would only be made for the destination URL. URLs for any  
>> relays would be expressed the same way they are now.
>>
>> The advantage of this approach is that it more closely follows the  
>> spirit of SDP. This will be easier to understand for people who  
>> already know SDP. Existing SDP code could be reused more effectively.
>>
>> The disadvantage of the proposed change is, it means the way an MSRP  
>> client determines the destination URL would be different depending on  
>> whether the URL represented the final destination or a relay. Instead  
>> of the current approach of simply copying the path attribute value  
>> into the To-Path header in MSRP messages,  a client would copy the  
>> path header value if exists, reconstitute the destination URL from 
>> the  m and c lines, and append the destination URL to the path header  
>> value.
>>
>> So, what do people think? (I note that we actually did something  
>> similar to this before we added the "path" attribute. )
>>
>>
>> Thanks!
>>
>> Ben.
>>
>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>>
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Sun Dec 12 15:04:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25261;
	Sun, 12 Dec 2004 15:04:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cda5M-0006mO-Um; Sun, 12 Dec 2004 15:12:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdZqm-0001Up-4k; Sun, 12 Dec 2004 14:57:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdZo5-0000zv-L9; Sun, 12 Dec 2004 14:55:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24456;
	Sun, 12 Dec 2004 14:55:00 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdZvk-0006Yk-UB; Sun, 12 Dec 2004 15:02:57 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-2.cisco.com with ESMTP; 12 Dec 2004 11:57:59 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBCJsM5M029272;
	Sun, 12 Dec 2004 11:54:23 -0800 (PST)
Received: from cisco.com (che-vpn-cluster-2-34.cisco.com [10.86.242.34])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANQ53245;
	Sun, 12 Dec 2004 14:54:17 -0500 (EST)
Message-ID: <41BCA1E9.8080007@cisco.com>
Date: Sun, 12 Dec 2004 14:54:17 -0500
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: Joerg Ott <jo@tzi.uni-bremen.de>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>	<6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
	<41BC325D.4010808@tzi.uni-bremen.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org, Colin Perkins <csp@csperkins.org>,
        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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit



Joerg Ott wrote:
> I agree with Colin on the ugliness issue of decomposing URLs into
> c= and m= lines.  But this is the way SDP has worked and works today.
> 
> The present discussion we are having here is about changing SDP to
> for address/URL handling in one particular case.  This does not
> strike me as something MSRP should be concerned with.
> 
> I would like to make one thing clear: we are either using existing tools
> in another document or we are building new ones.  There is nothing much
> in between.
> 
> Changing c=/m= semantics means changing SDP.  Just because the syntax
> still looks the same does not mean that it is still the same protocol.
> Any entity or generic protocol engine used to dealing with SDP m=/c=
> would no longer do the right thing.

Can you explain what sort of generic processing of SDP that would break 
as a result of this change, but would not break as a result of adding 
MSRP in a syntax you have in mind?

There is really only a minimal amount of generic processing that can be 
done for SDP as it stands. That doesn't include actual management of 
sockets, since that is all dependent on "transport". I have worked with 
an SDP "stack", and it isn't harmed in any way by the usage proposed in 
MSRP.

The work that will be needed to support MSRP will only be made more 
complex by tearing info out of a URL and pasting it into the c- and m- 
lines.

> We see this kind of approach quite often -- by far too often -- over
> the past years (just think the many "uses" of SIP defined elsewhere,
> usually resulting in something "a little but not entirely unlike" SIP).
> 
> What I would like avoid is having special treatment of SDP depending
> on what the media type is (or other attributes signify).

Then why not just restrict SDP to use with RTP transports? That covers 
what it seems to have been designed for. Half the stuff defined in SDP 
is only applicable in that case. It has also been a real stretch to 
apply SDP to the offer/answer needs of SIP. Maybe that was an abuse too.

> Therefore, I strongly agree with Colin's conclusion: take SDP as is
> or leave it altogether and pursue a different path.

Right! Given that the only alternative in sight is SDPng, and apparently 
nobody as any belief that it will be adopted in our lifetimes.

	Paul

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


From simple-bounces@ietf.org  Mon Dec 13 04:23:39 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14651;
	Mon, 13 Dec 2004 04:23:39 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdmYR-0008FX-9f; Mon, 13 Dec 2004 04:31:43 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdmOp-0002gT-VH; Mon, 13 Dec 2004 04:21:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdmEC-0007Z5-CO; Mon, 13 Dec 2004 04:10:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12657;
	Mon, 13 Dec 2004 04:10:46 -0500 (EST)
Received: from voyager.coretrek.no ([212.33.142.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdmLx-0007t5-Pz; Mon, 13 Dec 2004 04:18:51 -0500
Received: from localhost (localhost [127.0.0.1])
	by voyager.coretrek.no (Postfix) with ESMTP
	id 8DC7BA9567; Mon, 13 Dec 2004 10:10:14 +0100 (CET)
Received: from [192.168.1.67] (unknown [82.196.203.62])
	by voyager.coretrek.no (Postfix) with ESMTP
	id C801DA9560; Mon, 13 Dec 2004 10:10:12 +0100 (CET)
In-Reply-To: <41BC325D.4010808@tzi.uni-bremen.de>
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
	<6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
	<41BC325D.4010808@tzi.uni-bremen.de>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C7C9823E-4CE6-11D9-8A90-000D93C60BA0@telio.no>
Content-Transfer-Encoding: 7bit
From: Hisham Khartabil <hisham.khartabil@telio.no>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
Date: Mon, 13 Dec 2004 10:10:06 +0100
To: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Apple Mail (2.619)
X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org, Colin Perkins <csp@csperkins.org>,
        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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: 7bit

(not as chair, but as an MSRP protocol contributor)

The objection to using the SDP c and m lines is not purely a cosmetic 
objection. We are not saying that SDP the way it is defined today is 
ugly so we want to rearrange it to look better.

We have a fundamental objection: having 2 ways to construct a next hop 
URI that depends on the entity that is the next hop is not acceptable. 
Endpoints should not be required  to have 2 engines implemented. Unless 
we are given an alternative that allows endpoint implementers to 
implement one piece of code for constructing an next hop MSRP URI, I'm 
afraid we have no choice but to keep what we have today in MSRP as is.

You telling us to go find another protocol if we don't like SDP the way 
it is today is hardly contructive. SDPng is not an option and we call 
know it.

Let me add that comedia also violates what you claim to be a 
fundamental piece of the protocol that if broken will cause the SDP 
protocol not to be SDP any longer. An argument that I don't buy. We 
have violated things before:

    - t= line does not mean anything in SIP and is set to 0 0 (which in 
SDP means that the session is permanent and unbounded).
    - s= line carries session name. It is set to - when used with SIP.

Also, quoting the SDP draft:

"For unicast IP sessions, the following are conveyed:

    o  The remote address for media

    o  The remote transport port for media

    The semantics of this address and port depend on the media and
    transport protocol defined.  By default, this SHOULD be the remote
    address and remote port to which data is sent.  Some media types MAY
    redefine this behaviour, but this is NOT RECOMMENDED."

We are changing the semantics. As far as I understand from the quoted 
paragraph above, we are not violating anything, even-though it is not 
recommended.

I have a question to SDP stack implementers that plan to implement 
MSRP: Does the current way MSRP specifies the use of SDP (ignore the c 
line address and the m line port and instead use the attribute a=path) 
cause problems to you and requires you to do some hacking in your SDP 
stack? If so, is that acceptable or do you prefer for your MSRP 
implementation to implement two ways of contructing an MSRP URL 
depending on the what the next hop is?

Regards,
Hisham

On Dec 12, 2004, at 12:58 PM, Joerg Ott wrote:

> I agree with Colin on the ugliness issue of decomposing URLs into
> c= and m= lines.  But this is the way SDP has worked and works today.
>
> The present discussion we are having here is about changing SDP to
> for address/URL handling in one particular case.  This does not
> strike me as something MSRP should be concerned with.
>
> I would like to make one thing clear: we are either using existing 
> tools
> in another document or we are building new ones.  There is nothing much
> in between.
>
> Changing c=/m= semantics means changing SDP.  Just because the syntax
> still looks the same does not mean that it is still the same protocol.
> Any entity or generic protocol engine used to dealing with SDP m=/c=
> would no longer do the right thing.
>
> We see this kind of approach quite often -- by far too often -- over
> the past years (just think the many "uses" of SIP defined elsewhere,
> usually resulting in something "a little but not entirely unlike" SIP).
>
> What I would like avoid is having special treatment of SDP depending
> on what the media type is (or other attributes signify).
>
> Therefore, I strongly agree with Colin's conclusion: take SDP as is
> or leave it altogether and pursue a different path.
>
> Joerg
>
>
> Colin Perkins wrote:
>
>> On 10 Dec 2004, at 21:41, Ben Campbell wrote:
>>> I really need to get closure on this, so I'd appreciate people 
>>> agreeing or disagreeing.
>>>
>>> I have had off-list correspondence indicating both positions. In 
>>> summary:
>>>
>>> In favor of the change, I had a comment to the effect that changing 
>>> SDP semantics to ignore the C line and the port field on the M line 
>>> really changes it to something that is no longer SDP, and that such 
>>> deviations are in general bad for interop.
>>>
>>> In favor of leaving things as currently specified, I had two 
>>> comments that decomposing URLs into the C and M lines is ugly, and 
>>> that having a different mechanism to communicate endpoint addresses 
>>> vs relay addresses is really ugly.
>>>
>>> So, do people agree with one or the other position?
>> Decomposing the URL into the "c=" and "m=" lines is very ugly. 
>> Unfortunately, that ugliness is required if you want to use SDP. This 
>> is why the SDPng work was started, to try to move to something less 
>> horrible...
>> Colin
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>


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


From simple-bounces@ietf.org  Mon Dec 13 06:13:57 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23326;
	Mon, 13 Dec 2004 06:13:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdoHD-0002B2-2P; Mon, 13 Dec 2004 06:22:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cdo2V-0007qQ-2I; Mon, 13 Dec 2004 06:06:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cdo1r-0007g0-Ar; Mon, 13 Dec 2004 06:06:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22751;
	Mon, 13 Dec 2004 06:06:09 -0500 (EST)
Received: from cmailg4.svr.pol.co.uk ([195.92.195.174])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cdo9e-00021K-MT; Mon, 13 Dec 2004 06:14:15 -0500
Received: from user-3843.l6.c4.dsl.pol.co.uk ([84.65.47.3] helo=RW)
	by cmailg4.svr.pol.co.uk with smtp (Exim 4.41)
	id 1Cdo1l-0005tL-DF; Mon, 13 Dec 2004 11:06:05 +0000
Message-ID: <003a01c4e103$be9cb8f0$c700a8c0@RW>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: <iesg@ietf.org>
References: <E1CcVo8-0005tm-U3@megatron.ietf.org>
Subject: Re: [Simple] Last Call: 'The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)' to Proposed Standard 
Date: Mon, 13 Dec 2004 11:06:02 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit

I haven't followed XCAP, but I wonder if the following XML schema types
should be empty elements (e.g. <not-well-formed/>) rather than ur-type (e.g.
<not-well-formed>blah<foo/>etc</not-well-formed>)?

    <xs:element name="not-well-formed" substitutionGroup="error-element">
    </xs:element>
    <xs:element name="constraint-failure" substitutionGroup="error-element">
    </xs:element>
    <xs:element name="cannot-delete">
    </xs:element>

If some of them are meant to be empty, then the syntax is:

    <xs:element name="not-well-formed" substitutionGroup="error-element">
      <xs:complexType/>
    </xs:element>
    <xs:element name="constraint-failure" substitutionGroup="error-element">
      <xs:complexType/>
    </xs:element>
    <xs:element name="cannot-delete">
      <xs:complexType/>
    </xs:element>

Regards,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware
http://www.tech-know-ware.com/lmx
For LMX XML to C++ binding
(or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "The IESG" <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: <simple@ietf.org>
Sent: Thursday, December 09, 2004 9:26 PM
Subject: [Simple] Last Call: 'The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)' to Proposed Standard


> The IESG has received a request from the SIP for Instant Messaging and
> Presence Leveraging Extensions WG to consider the following document:
>
> - 'The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) '
>    <draft-ietf-simple-xcap-05.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-28.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt
>
>
> _______________________________________________
> 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 Dec 13 07:06:44 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27985;
	Mon, 13 Dec 2004 07:06:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cdp69-0003Np-7J; Mon, 13 Dec 2004 07:14:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cdowx-0004k0-1b; Mon, 13 Dec 2004 07:05:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdowK-0004Wk-RW
	for simple@megatron.ietf.org; Mon, 13 Dec 2004 07:04:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27642
	for <simple@ietf.org>; Mon, 13 Dec 2004 07:04:30 -0500 (EST)
Received: from penguin.ericsson.se ([193.180.251.47])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdp3u-0003Jc-Bp
	for simple@ietf.org; Mon, 13 Dec 2004 07:12:37 -0500
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	iBDC4Gh5025468
	for <simple@ietf.org>; Mon, 13 Dec 2004 13:04:16 +0100 (MET)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by
	esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 13 Dec 2004 13:04:16 +0100
Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13])
	by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id YLNLQMTJ; Mon, 13 Dec 2004 13:04:15 +0100
Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196])
	by mail.lmf.ericsson.se (Postfix) with ESMTP
	id 9E16718A90; Mon, 13 Dec 2004 14:04:14 +0200 (EET)
Message-ID: <41BD853E.7070400@ericsson.com>
Date: Mon, 13 Dec 2004 14:04:14 +0200
X-Sybari-Trust: c2ac6c96 96d33411 8187bc11 00000138
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] MSRP: sdp usage compared to BFCP
References: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>
In-Reply-To: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Dec 2004 12:04:16.0208 (UTC)
	FILETIME=[DE345D00:01C4E10B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        Simple WG <simple@ietf.org>, Robert Sparks <RjS@xten.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit

Hi Ben,

> In the DC meeting, Gonzalo asked us to compare how MSRP and BFCP use 
> SDP. Since they are both connection oriented, this seems to be a 
> sensible thing to do. So, I took a shot at it;

thanks for putting this together.

> 1) BFCP depends on COMEDIA. MSRP does not.
> 
> The reason MSRP does not invoke COMEDIA is mainly a historic one. At the 
> time we wrote that part of the spec, COMEDIA had not progressed as far 
> as it has now. Instead, MSRP states a default connection "direction", 
> and says that other mechanisms can be used to determine direction once 
> they become standardized.

The thing is that, most likely, comedia will be ready before both BFCP 
and MSRP. So, arguing that comedia will not be ready is not a valid 
argument anymore.

Comedia defines two SDP attributes (setup and connection) that are used 
to figure out which end initiates the TCP connection and, on reception 
of a new offer, whether the TCP connection needs to be re-established or 
the existing TCP connection is OK.

I do not think that using these attributes would add too much complexity 
to the protocol and having a way to know whether or not an offer implies 
that the TCP connection needs to be re-established but the rest of the 
parameters should not change seems like important funcionality. So, even 
if you want to avoid using the setup attribute (for some reason) by 
defining a default connection initiator, I believe you may still want to 
use the connection attribute.

> 2) MSRP uses a URL in an a-line attribute to determine where to connect 
> (address, port, protocol). I _think_ BFCP uses the traditional mechanism 
> of an address in the c-line and a port in the m-line. This is not 
> entirely clear to me, as the BFCP SDP draft says in one paragraph that 
> the port is always ignored, and in another paragraph that the m-line 
> port is the port too which a client connects. I gather the point is to 
> say that the m-line port is only meaningful to the peer that opens the 
> TCP connection. Along the same line, BFCP uses the m-line format field 
> to determine whether to invoke TLS, while MSRP uses the URL in the path 
> attribute.
> 
> The main reason is that MSRP uses URLs in the path attribute is, it must 
> be able to communicate a path of URLs, rather than a single URL.  That 
> does not appear to be an issue with BFCP. There has been some recent 
> controversy the MSRP usage. I will send a summary of that in a separate 
> email.

I do not have any problem with MSRP using URIs instead of a c-line type 
of format.

> 3) Both MSRP and BFCP use a "*" in the m-line fmt-list field. But I 
> think this is for different reasons. MSRP does this because it uses 
> a-line attributes to determine the acceptable formats. I gather BFCP 
> does this because content-type negotiation is not relevant to it.
> 
> It seems to me that each of these differences are due to semantic 
> differences between the two protocols. That is, they are appropriately 
> different.

I agree.

> 
> I welcome any discussion, both on whether I interpreted the BFCP SDP 
> usage correctly, and whether the differences are really appropriate.

In my opinion, differences in 2) and 3) are OK, but regarding 1), we may 
want to use the connection attribute (and maybe the setup attribute as 
well) in MSRP as well, as I said earlier.

Thanks,

Gonzalo


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


From simple-bounces@ietf.org  Mon Dec 13 09:24:05 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12802;
	Mon, 13 Dec 2004 09:24:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdrFC-0007OA-KM; Mon, 13 Dec 2004 09:32:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdqlV-0005BN-QY; Mon, 13 Dec 2004 09:01:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdqdb-0001Z3-NJ
	for simple@megatron.ietf.org; Mon, 13 Dec 2004 08:53:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09667
	for <simple@ietf.org>; Mon, 13 Dec 2004 08:53:18 -0500 (EST)
Received: from mgw-x2.nokia.com ([131.228.20.22])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdqlQ-0006Mz-HF
	for simple@ietf.org; Mon, 13 Dec 2004 09:01:24 -0500
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBDDm3r02256; Mon, 13 Dec 2004 15:48:05 +0200 (EET)
X-Scanned: Mon, 13 Dec 2004 15:43:48 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBDDhmaU000423;
	Mon, 13 Dec 2004 15:43:48 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00mqu5do; Mon, 13 Dec 2004 15:43:47 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBDDhGD14583; Mon, 13 Dec 2004 15:43:16 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh003.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Mon, 13 Dec 2004 15:41:09 +0200
Message-ID: <41BD9BF5.3040109@nokia.com>
Date: Mon, 13 Dec 2004 15:41:09 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Cullen Jennings <fluffy@cisco.com>,
        Rohan Mahy <rohan@ekabal.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Dec 2004 13:41:09.0756 (UTC)
	FILETIME=[675963C0:01C4E119]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>
Subject: [Simple] MSRP URLs
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit

A question about MSRP URLs.

I noticed that the MSRP draft defines URLs to be of the following format:

msrp://alice.example.com:3092/32dk;tcp

whereas the MSRP-relays draft don't uses the "//". For instance:

msrp:a.example.com:1234/agic456;tcp

and

msrps:alice@intra.example.com

So do MSRP URLs contain "//" or not? If yes, how to accommodate 
usernames in the URL?

I guess one or the other draft have to change something...

Regards,

       Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Mon Dec 13 09:49:15 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15399;
	Mon, 13 Dec 2004 09:49:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdrdZ-0008B2-1C; Mon, 13 Dec 2004 09:57:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdrK2-0000lx-LY; Mon, 13 Dec 2004 09:37:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdr9y-0005Yk-JM
	for simple@megatron.ietf.org; Mon, 13 Dec 2004 09:26:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13068
	for <simple@ietf.org>; Mon, 13 Dec 2004 09:26:45 -0500 (EST)
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdrHm-0007Tz-Ko
	for simple@ietf.org; Mon, 13 Dec 2004 09:34:52 -0500
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBDELcD22450; Mon, 13 Dec 2004 16:21:40 +0200 (EET)
X-Scanned: Mon, 13 Dec 2004 16:19:10 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBDEJAoc010507;
	Mon, 13 Dec 2004 16:19:10 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks004.ntc.nokia.com 00JHGdPX; Mon, 13 Dec 2004 16:16:07 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBDEG6306578; Mon, 13 Dec 2004 16:16:06 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh003.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Mon, 13 Dec 2004 16:14:42 +0200
Message-ID: <41BDA3D1.4040004@nokia.com>
Date: Mon, 13 Dec 2004 16:14:41 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Dec 2004 14:14:42.0618 (UTC)
	FILETIME=[171BC1A0:01C4E11E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>
Subject: [Simple] MSRP: IANA considerations
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit

About MSRP and the IANA considerations: I noticed that MSRP does not 
register any method, header, response code, etc. Then, MSRP relays says 
in section 9 that there are no new requirements to IANA:

Isn't this a bit mess without such registry? I would expect that MSRP 
follows a similar policy than SIP. I would expect MSRP to open a new 
MSRP registry with sub-registries for methods, headers, responses, etc.

Let's take MSRP-Relays. However, at least I have detected quite a few 
new "things" to be registered with IANA. Essentially, everything 
described under Section 4, "Overview of New Protocol Elements"

- New method: AUTH

- New headers: Use-Path, Authorization, WWW-Authenticate, 
Authentication-Info, Expires, Min-Expires, Max-Expires

- New response code: 423 Out-of-bounds

By the way: I am missing 401 Unauthorized from the above list in Section 4.

Don't you think it would be easier to establish a registry with all 
those sub-registries?

Regards,

           Miguel



-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Mon Dec 13 11:00:18 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22329;
	Mon, 13 Dec 2004 11:00:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdskB-0001Wk-Sc; Mon, 13 Dec 2004 11:08:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdsNt-0000Uw-6p; Mon, 13 Dec 2004 10:45:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdsIV-0006rt-GD
	for simple@megatron.ietf.org; Mon, 13 Dec 2004 10:39:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20384
	for <simple@ietf.org>; Mon, 13 Dec 2004 10:39:37 -0500 (EST)
Received: from albatross.ericsson.se ([193.180.251.49])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdsQ9-0000xd-SS
	for simple@ietf.org; Mon, 13 Dec 2004 10:47:45 -0500
Received: from esealmw127.eemea.ericsson.se ([153.88.254.122])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	iBDFYevD013946; Mon, 13 Dec 2004 16:34:40 +0100 (MET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 13 Dec 2004 16:34:38 +0100
Received: from [147.214.34.68] ([147.214.34.68]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 13 Dec 2004 16:34:38 +0100
Message-ID: <41BDB68E.3000504@ericsson.com>
Date: Mon, 13 Dec 2004 16:34:38 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Subject: Re: [Simple] MSRP URLs
References: <41BD9BF5.3040109@nokia.com>
In-Reply-To: <41BD9BF5.3040109@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Dec 2004 15:34:38.0053 (UTC)
	FILETIME=[41691150:01C4E129]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Simple WG <simple@ietf.org>,
        Rohan Mahy <rohan@ekabal.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: 7bit

Hi Miguel,

If you look in RFC 2396, you will see that also with // it is allowed to 
have an optional username part of the authority if you accept using a 
hierarchical URI. However as I don't know MSRP sufficiently I don't know 
if that is suitable.


 From Section 3 of 2396:
       absoluteURI   = scheme ":" ( hier_part | opaque_part )

       hier_part     = ( net_path | abs_path ) [ "?" query ]

       net_path      = "//" authority [ abs_path ]

       abs_path      = "/"  path_segments
	
       authority     = server | reg_name

       server        = [ [ userinfo "@" ] hostport ]

       opaque_part   = uric_no_slash *uric

       uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                       "&" | "=" | "+" | "$" | ","


But it seems that some work on clarifying the URI definition is 
necessary if the drafts can't answer your question.

Cheers

Magnus

Miguel Garcia wrote:
> A question about MSRP URLs.
> 
> I noticed that the MSRP draft defines URLs to be of the following format:
> 
> msrp://alice.example.com:3092/32dk;tcp
> 
> whereas the MSRP-relays draft don't uses the "//". For instance:
> 
> msrp:a.example.com:1234/agic456;tcp
> 
> and
> 
> msrps:alice@intra.example.com
> 
> So do MSRP URLs contain "//" or not? If yes, how to accommodate
> usernames in the URL?
> 
> I guess one or the other draft have to change something...
> 
> Regards,
> 
>        Miguel
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 


-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

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


From simple-bounces@ietf.org  Mon Dec 13 11:22:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24254;
	Mon, 13 Dec 2004 11:22:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cdt67-00025A-3O; Mon, 13 Dec 2004 11:30:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cdslq-0006rd-TY; Mon, 13 Dec 2004 11:09:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdsWG-0003Km-Hm
	for simple@megatron.ietf.org; Mon, 13 Dec 2004 10:53:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21727
	for <simple@ietf.org>; Mon, 13 Dec 2004 10:53:50 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdse6-0001Jr-3P
	for simple@ietf.org; Mon, 13 Dec 2004 11:01:58 -0500
Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBDFmeJB024642
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 13 Dec 2004 09:48:41 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <41BDB68E.3000504@ericsson.com>
References: <41BD9BF5.3040109@nokia.com> <41BDB68E.3000504@ericsson.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <748D77C8-4D1E-11D9-91F3-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] MSRP URLs
Date: Mon, 13 Dec 2004 09:48:38 -0600
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: 7bit
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Rohan Mahy <rohan@ekabal.com>,
        Simple WG <simple@ietf.org>, Cullen Jennings <fluffy@cisco.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: 7bit

The MSRP URL uses the "//" notation, and userinfo is allowed. It sounds 
like the relay draft has a bug here.

BTW, the userinfo construction is only mildly useful for MSRP. The only 
usage I can think of is a syntax to tell a relay aware client to 
authenticate to a particular relay using a particular user name. It 
explicitly does _not_ have an semantics for disambiguating MSRP 
sessions.



On Dec 13, 2004, at 9:34 AM, Magnus Westerlund wrote:

> Hi Miguel,
>
> If you look in RFC 2396, you will see that also with // it is allowed 
> to have an optional username part of the authority if you accept using 
> a hierarchical URI. However as I don't know MSRP sufficiently I don't 
> know if that is suitable.
>
>
> From Section 3 of 2396:
>       absoluteURI   = scheme ":" ( hier_part | opaque_part )
>
>       hier_part     = ( net_path | abs_path ) [ "?" query ]
>
>       net_path      = "//" authority [ abs_path ]
>
>       abs_path      = "/"  path_segments
> 	
>       authority     = server | reg_name
>
>       server        = [ [ userinfo "@" ] hostport ]
>
>       opaque_part   = uric_no_slash *uric
>
>       uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
>                       "&" | "=" | "+" | "$" | ","
>
>
> But it seems that some work on clarifying the URI definition is 
> necessary if the drafts can't answer your question.
>
> Cheers
>
> Magnus
>
> Miguel Garcia wrote:
>> A question about MSRP URLs.
>> I noticed that the MSRP draft defines URLs to be of the following 
>> format:
>> msrp://alice.example.com:3092/32dk;tcp
>> whereas the MSRP-relays draft don't uses the "//". For instance:
>> msrp:a.example.com:1234/agic456;tcp
>> and
>> msrps:alice@intra.example.com
>> So do MSRP URLs contain "//" or not? If yes, how to accommodate
>> usernames in the URL?
>> I guess one or the other draft have to change something...
>> Regards,
>>        Miguel
>> -- 
>> Miguel A. Garcia           tel:+358-50-4804586
>> Nokia Research Center      Helsinki, Finland
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>
>
> -- 
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


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


From simple-bounces@ietf.org  Mon Dec 13 11:58:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27930;
	Mon, 13 Dec 2004 11:58:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cdtex-0003Ad-KP; Mon, 13 Dec 2004 12:06:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdtLn-0003c0-UN; Mon, 13 Dec 2004 11:47:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdtEn-0000Up-Hs
	for simple@megatron.ietf.org; Mon, 13 Dec 2004 11:39:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26452
	for <simple@ietf.org>; Mon, 13 Dec 2004 11:39:51 -0500 (EST)
Received: from figas.ekabal.com ([204.61.215.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdtMc-0002dx-M2
	for simple@ietf.org; Mon, 13 Dec 2004 11:48:00 -0500
Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88])
	(authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id iBDGcXX15826;
	Mon, 13 Dec 2004 08:38:43 -0800
In-Reply-To: <41BD9BF5.3040109@nokia.com>
References: <41BD9BF5.3040109@nokia.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <68CE0F6C-4D25-11D9-BC20-000D93C60450@ekabal.com>
Content-Transfer-Encoding: 7bit
From: Rohan Mahy <rohan@ekabal.com>
Date: Mon, 13 Dec 2004 08:38:25 -0800
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Simple WG <simple@ietf.org>,
        Rohan Mahy <rohan@ekabal.com>
Subject: [Simple] Re: MSRP URLs
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit

Hi Miguel,

Thanks for pointing that out.  The relay draft is supposed to be 
dependent on the base draft, so we'll fix this in the next rev.

thx,
-r



On Dec 13, 2004, at 5:41, Miguel Garcia wrote:

> A question about MSRP URLs.
>
> I noticed that the MSRP draft defines URLs to be of the following 
> format:
>
> msrp://alice.example.com:3092/32dk;tcp
>
> whereas the MSRP-relays draft don't uses the "//". For instance:
>
> msrp:a.example.com:1234/agic456;tcp
>
> and
>
> msrps:alice@intra.example.com
>
> So do MSRP URLs contain "//" or not? If yes, how to accommodate 
> usernames in the URL?
>
> I guess one or the other draft have to change something...
>
> Regards,
>
>       Miguel
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland


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


From simple-bounces@ietf.org  Mon Dec 13 12:00:15 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28144;
	Mon, 13 Dec 2004 12:00:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdtgO-0003Dq-Bo; Mon, 13 Dec 2004 12:08:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdtMe-0004Ju-PM; Mon, 13 Dec 2004 11:48:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdtHl-0001eG-RF
	for simple@megatron.ietf.org; Mon, 13 Dec 2004 11:42:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27014
	for <simple@ietf.org>; Mon, 13 Dec 2004 11:42:54 -0500 (EST)
Received: from figas.ekabal.com ([204.61.215.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdtPb-0002nq-Dp
	for simple@ietf.org; Mon, 13 Dec 2004 11:51:03 -0500
Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88])
	(authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id iBDGeNX15849;
	Mon, 13 Dec 2004 08:40:34 -0800
In-Reply-To: <748D77C8-4D1E-11D9-91F3-000D93B0AE1A@nostrum.com>
References: <41BD9BF5.3040109@nokia.com> <41BDB68E.3000504@ericsson.com>
	<748D77C8-4D1E-11D9-91F3-000D93B0AE1A@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <AAA4F340-4D25-11D9-BC20-000D93C60450@ekabal.com>
Content-Transfer-Encoding: 7bit
From: Rohan Mahy <rohan@ekabal.com>
Subject: Re: [Simple] MSRP URLs
Date: Mon, 13 Dec 2004 08:40:15 -0800
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Simple WG <simple@ietf.org>,
        Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit


On Dec 13, 2004, at 7:48, Ben Campbell wrote:

> BTW, the userinfo construction is only mildly useful for MSRP. The 
> only usage I can think of is a syntax to tell a relay aware client to 
> authenticate to a particular relay using a particular user name.

... and we are in fact using this the relay draft (at least in an 
example)

>  It explicitly does _not_ have an semantics for disambiguating MSRP 
> sessions.

agreed.
thx,
-r

>
>
> On Dec 13, 2004, at 9:34 AM, Magnus Westerlund wrote:
>
>> Hi Miguel,
>>
>> If you look in RFC 2396, you will see that also with // it is allowed 
>> to have an optional username part of the authority if you accept 
>> using a hierarchical URI. However as I don't know MSRP sufficiently I 
>> don't know if that is suitable.
>>
>>
>> From Section 3 of 2396:
>>       absoluteURI   = scheme ":" ( hier_part | opaque_part )
>>
>>       hier_part     = ( net_path | abs_path ) [ "?" query ]
>>
>>       net_path      = "//" authority [ abs_path ]
>>
>>       abs_path      = "/"  path_segments
>> 	
>>       authority     = server | reg_name
>>
>>       server        = [ [ userinfo "@" ] hostport ]
>>
>>       opaque_part   = uric_no_slash *uric
>>
>>       uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
>>                       "&" | "=" | "+" | "$" | ","
>>
>>
>> But it seems that some work on clarifying the URI definition is 
>> necessary if the drafts can't answer your question.
>>
>> Cheers
>>
>> Magnus
>>
>> Miguel Garcia wrote:
>>> A question about MSRP URLs.
>>> I noticed that the MSRP draft defines URLs to be of the following 
>>> format:
>>> msrp://alice.example.com:3092/32dk;tcp
>>> whereas the MSRP-relays draft don't uses the "//". For instance:
>>> msrp:a.example.com:1234/agic456;tcp
>>> and
>>> msrps:alice@intra.example.com
>>> So do MSRP URLs contain "//" or not? If yes, how to accommodate
>>> usernames in the URL?
>>> I guess one or the other draft have to change something...
>>> Regards,
>>>        Miguel
>>> -- 
>>> Miguel A. Garcia           tel:+358-50-4804586
>>> Nokia Research Center      Helsinki, Finland
>>> _______________________________________________
>>> Simple mailing list
>>> Simple@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/simple
>>
>>
>> -- 
>>
>> Magnus Westerlund
>>
>> Multimedia Technologies, Ericsson Research EAB/TVA/A
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone +46 8 4048287
>> Torshamsgatan 23           | Fax   +46 8 7575550
>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


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


From simple-bounces@ietf.org  Mon Dec 13 12:49:46 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02355;
	Mon, 13 Dec 2004 12:49:46 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CduSK-0004WK-CR; Mon, 13 Dec 2004 12:57:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CduA4-0006yS-4n; Mon, 13 Dec 2004 12:39:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cdu4M-0004RC-Ve; Mon, 13 Dec 2004 12:33:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01069;
	Mon, 13 Dec 2004 12:33:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CduCE-00047W-2e; Mon, 13 Dec 2004 12:41:18 -0500
Received: from apache by megatron.ietf.org with local (Exim 4.32)
	id 1Cdtui-0001Ak-Uy; Mon, 13 Dec 2004 12:23:12 -0500
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1Cdtui-0001Ak-Uy@megatron.ietf.org>
Date: Mon, 13 Dec 2004 12:23:12 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: simple@ietf.org
Subject: [Simple] Last Call: 'Extensible Markup Language (XML) Formats for
 Representing Resource Lists' to Proposed Standard 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

The IESG has received a request from the SIP for Instant Messaging and 
Presence Leveraging Extensions WG to consider the following document:

- 'Extensible Markup Language (XML) Formats for Representing Resource Lists '
   <draft-ietf-simple-xcap-list-usage-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-28.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-04.txt


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


From simple-bounces@ietf.org  Tue Dec 14 00:10:12 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01803;
	Tue, 14 Dec 2004 00:10:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ce54t-0005Df-Ba; Tue, 14 Dec 2004 00:18:28 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ce4vu-0006p1-SY; Tue, 14 Dec 2004 00:09:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ce4rP-0006S9-7W; Tue, 14 Dec 2004 00:04:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01151;
	Tue, 14 Dec 2004 00:04:28 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ce4zL-00054K-A1; Tue, 14 Dec 2004 00:12:44 -0500
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 13 Dec 2004 21:04:07 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iBE53u6n005775;
	Mon, 13 Dec 2004 21:03:57 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-1-130.cisco.com
	[10.86.240.130]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGH81164; Mon, 13 Dec 2004 21:03:56 -0800 (PST)
Message-ID: <41BE743B.8040003@cisco.com>
Date: Tue, 14 Dec 2004 00:03:55 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'geopriv@ietf.org'" <geopriv@ietf.org>, Simple WG <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Subject: [Simple] Usage of substitution groups in
	draft-ietf-geopriv-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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit

Folks,

In several of the simple and geopriv specifications, we are making use 
of XML substitution groups as the mechanism for document extensibility. 
These include draft-ietf-geopriv-common-policy, which is extended by 
draft-ietf-simple-presence-rules.

However, it appears that substitution groups introduce some limitations. 
Most important amongst them is that, in order to be validated against 
the schema for the baseline document, the entity doing the validation 
must be aware of the schemas for all namespaces for elements that are 
part of the substitution group. This doesn't work well in cases where we 
expect the entity creating the document to be making use of extensions 
that the entity doing the validation isn't going to be aware of (and 
shouldn't need to be).

This is particularly problematic for draft-ietf-simple-presence-rules, 
where we expect to use xcap to manipulate the documents. The xcap server 
needs to be able to validate the document according to the baseline 
schema, but it should not be required to know about all of the 
extensions that we might see in order to process the document. Right 
now, it would have to.

As a result, I'd suggest that draft-ietf-geopriv-common-policy make use 
of the <any> constructs for defining extensibility, rather than 
substitution groups.

Comments?

-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 Dec 14 02:08:00 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18430;
	Tue, 14 Dec 2004 02:08:00 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ce6ut-0007mB-Aa; Tue, 14 Dec 2004 02:16:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ce6ku-0006so-Jh; Tue, 14 Dec 2004 02:05:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ce6iK-00051H-QT; Tue, 14 Dec 2004 02:03:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13564;
	Tue, 14 Dec 2004 02:03:16 -0500 (EST)
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ce6qH-0007gm-MD; Tue, 14 Dec 2004 02:11:31 -0500
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBE735K03871; Tue, 14 Dec 2004 09:03:10 +0200 (EET)
X-Scanned: Tue, 14 Dec 2004 09:01:24 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBE71Orx007876;
	Tue, 14 Dec 2004 09:01:24 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks004.ntc.nokia.com 00FD5sT3; Tue, 14 Dec 2004 09:01:21 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBE71H328895; Tue, 14 Dec 2004 09:01:17 +0200 (EET)
Received: from kusti.research.nokia.com ([172.21.56.13]) by
	esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 14 Dec 2004 09:00:58 +0200
Received: from [172.21.50.105] (xitami.research.nokia.com [172.21.50.105])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id D551A93B75; Tue, 14 Dec 2004 09:00:57 +0200 (EET)
Message-ID: <41BE8ED0.9090303@nokia.com>
Date: Tue, 14 Dec 2004 08:57:20 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] Usage of substitution groups
	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>
In-Reply-To: <41BE743B.8040003@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Dec 2004 07:00:58.0249 (UTC)
	FILETIME=[A9C9EF90:01C4E1AA]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, 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
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit

ext Jonathan Rosenberg wrote:

> Folks,
>
> In several of the simple and geopriv specifications, we are making use 
> of XML substitution groups as the mechanism for document 
> extensibility. These include draft-ietf-geopriv-common-policy, which 
> is extended by draft-ietf-simple-presence-rules.
>
> However, it appears that substitution groups introduce some 
> limitations. Most important amongst them is that, in order to be 
> validated against the schema for the baseline document, the entity 
> doing the validation must be aware of the schemas for all namespaces 
> for elements that are part of the substitution group. This doesn't 
> work well in cases where we expect the entity creating the document to 
> be making use of extensions that the entity doing the validation isn't 
> going to be aware of (and shouldn't need to be).
>
> This is particularly problematic for draft-ietf-simple-presence-rules, 
> where we expect to use xcap to manipulate the documents. The xcap 
> server needs to be able to validate the document according to the 
> baseline schema, but it should not be required to know about all of 
> the extensions that we might see in order to process the document. 
> Right now, it would have to.
>
> As a result, I'd suggest that draft-ietf-geopriv-common-policy make 
> use of the <any> constructs for defining extensibility, rather than 
> substitution groups.
>
> Comments?
>
> -Jonathan R.
>
Let's say you add a new extension e.g. <provide-dispatcher> 
transformation onto the presence rules. If you'll use <any> constraint 
in the schemas the server may validate the document although it may not 
"understand" this new transformation and the client may think that it 
will. However, if you'll use substitution groups and try to use this new 
extension the server will not validate this extension unless it has this 
new definition. So imo substitution groups provide much more consistent 
behavior in this case.  If these rules are stored within the xcap server 
the client can always query the server capabilities (which lists 
namespaces that it understands).

Of course there are situations where substitution groups don't 
necessarily fit that well, i.e. they may be too restrictive. However, I 
may have misunderstood where/how you'll want to use <any>...
br,
Jari

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


From simple-bounces@ietf.org  Tue Dec 14 06:09:06 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13288;
	Tue, 14 Dec 2004 06:09:06 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeAgG-0004nJ-G8; Tue, 14 Dec 2004 06:17:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeAWw-0004fP-V5; Tue, 14 Dec 2004 06:07:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeAVT-0004U3-Qe
	for simple@megatron.ietf.org; Tue, 14 Dec 2004 06:06:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13150
	for <simple@ietf.org>; Tue, 14 Dec 2004 06:06:13 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeAdS-0004jj-Rf
	for simple@ietf.org; Tue, 14 Dec 2004 06:14:32 -0500
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
	iBEAxuk27175; Tue, 14 Dec 2004 13:00:00 +0200 (EET)
X-Scanned: Tue, 14 Dec 2004 12:58:56 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iBEAwu3G024492;
	Tue, 14 Dec 2004 12:58:56 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00MLZk49; Tue, 14 Dec 2004 12:58:55 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBEAwnD23198; Tue, 14 Dec 2004 12:58:49 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 14 Dec 2004 12:58:41 +0200
Message-ID: <41BEC760.6030803@nokia.com>
Date: Tue, 14 Dec 2004 12:58:40 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [Simple] MSRP URLs
References: <41BD9BF5.3040109@nokia.com> <41BDB68E.3000504@ericsson.com>
In-Reply-To: <41BDB68E.3000504@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Dec 2004 10:58:41.0447 (UTC)
	FILETIME=[DF513B70:01C4E1CB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Simple WG <simple@ietf.org>,
        Rohan Mahy <rohan@ekabal.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit

Hi Magnus:

Although I agree with you, it must be noted that RFC 2396 is superceed 
by 2396bis (approved by the IESG, not yet RFCed). This does not change 
your comments though.

- Miguel

Magnus Westerlund wrote:
> Hi Miguel,
> 
> If you look in RFC 2396, you will see that also with // it is allowed to 
> have an optional username part of the authority if you accept using a 
> hierarchical URI. However as I don't know MSRP sufficiently I don't know 
> if that is suitable.
> 
> 
>  From Section 3 of 2396:
>       absoluteURI   = scheme ":" ( hier_part | opaque_part )
> 
>       hier_part     = ( net_path | abs_path ) [ "?" query ]
> 
>       net_path      = "//" authority [ abs_path ]
> 
>       abs_path      = "/"  path_segments
>     
>       authority     = server | reg_name
> 
>       server        = [ [ userinfo "@" ] hostport ]
> 
>       opaque_part   = uric_no_slash *uric
> 
>       uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
>                       "&" | "=" | "+" | "$" | ","
> 
> 
> But it seems that some work on clarifying the URI definition is 
> necessary if the drafts can't answer your question.
> 
> Cheers
> 
> Magnus
> 
> Miguel Garcia wrote:
> 
>> A question about MSRP URLs.
>>
>> I noticed that the MSRP draft defines URLs to be of the following format:
>>
>> msrp://alice.example.com:3092/32dk;tcp
>>
>> whereas the MSRP-relays draft don't uses the "//". For instance:
>>
>> msrp:a.example.com:1234/agic456;tcp
>>
>> and
>>
>> msrps:alice@intra.example.com
>>
>> So do MSRP URLs contain "//" or not? If yes, how to accommodate
>> usernames in the URL?
>>
>> I guess one or the other draft have to change something...
>>
>> Regards,
>>
>>        Miguel
>> -- 
>> Miguel A. Garcia           tel:+358-50-4804586
>> Nokia Research Center      Helsinki, Finland
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>>
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Tue Dec 14 06:14:03 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13712;
	Tue, 14 Dec 2004 06:14:03 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeAl4-0004vq-5e; Tue, 14 Dec 2004 06:22:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeAWx-0004fV-LJ; Tue, 14 Dec 2004 06:07:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeAVT-0004U4-Qy
	for simple@megatron.ietf.org; Tue, 14 Dec 2004 06:06:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13149
	for <simple@ietf.org>; Tue, 14 Dec 2004 06:06:13 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeAdS-0004ji-QQ
	for simple@ietf.org; Tue, 14 Dec 2004 06:14:32 -0500
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
	iBEAxpk27066; Tue, 14 Dec 2004 12:59:55 +0200 (EET)
X-Scanned: Tue, 14 Dec 2004 12:59:15 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iBEAxFB9025540;
	Tue, 14 Dec 2004 12:59:15 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00Q5wnz0; Tue, 14 Dec 2004 12:59:14 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBEAx7D23505; Tue, 14 Dec 2004 12:59:07 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 14 Dec 2004 12:59:08 +0200
Message-ID: <41BEC77B.40808@nokia.com>
Date: Tue, 14 Dec 2004 12:59:07 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Rohan Mahy <rohan@ekabal.com>
References: <41BD9BF5.3040109@nokia.com>
	<68CE0F6C-4D25-11D9-BC20-000D93C60450@ekabal.com>
In-Reply-To: <68CE0F6C-4D25-11D9-BC20-000D93C60450@ekabal.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Dec 2004 10:59:08.0121 (UTC)
	FILETIME=[EF375C90:01C4E1CB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Simple WG <simple@ietf.org>
Subject: [Simple] Re: MSRP URLs
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit

ok, thanks.

Rohan Mahy wrote:

> Hi Miguel,
> 
> Thanks for pointing that out.  The relay draft is supposed to be 
> dependent on the base draft, so we'll fix this in the next rev.
> 
> thx,
> -r
> 
> 
> 
> On Dec 13, 2004, at 5:41, Miguel Garcia wrote:
> 
>> A question about MSRP URLs.
>>
>> I noticed that the MSRP draft defines URLs to be of the following format:
>>
>> msrp://alice.example.com:3092/32dk;tcp
>>
>> whereas the MSRP-relays draft don't uses the "//". For instance:
>>
>> msrp:a.example.com:1234/agic456;tcp
>>
>> and
>>
>> msrps:alice@intra.example.com
>>
>> So do MSRP URLs contain "//" or not? If yes, how to accommodate 
>> usernames in the URL?
>>
>> I guess one or the other draft have to change something...
>>
>> Regards,
>>
>>       Miguel
>> -- 
>> Miguel A. Garcia           tel:+358-50-4804586
>> Nokia Research Center      Helsinki, Finland
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Tue Dec 14 06:22:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14088;
	Tue, 14 Dec 2004 06:22:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeAtf-00055Y-DL; Tue, 14 Dec 2004 06:31:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeAkU-00012s-0G; Tue, 14 Dec 2004 06:21:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeAjJ-0000Ru-Uy
	for simple@megatron.ietf.org; Tue, 14 Dec 2004 06:20:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14002
	for <simple@ietf.org>; Tue, 14 Dec 2004 06:20:31 -0500 (EST)
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeArK-000530-31
	for simple@ietf.org; Tue, 14 Dec 2004 06:28:50 -0500
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBEBFID04964; Tue, 14 Dec 2004 13:15:26 +0200 (EET)
X-Scanned: Tue, 14 Dec 2004 13:10:35 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iBEBAZ1J025232;
	Tue, 14 Dec 2004 13:10:35 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks003.ntc.nokia.com 00TgtxGh; Tue, 14 Dec 2004 13:10:34 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBEBAY319659; Tue, 14 Dec 2004 13:10:34 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 14 Dec 2004 13:10:27 +0200
Message-ID: <41BECA22.8020603@nokia.com>
Date: Tue, 14 Dec 2004 13:10:26 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Subject: Re: [Simple] MSRP: IANA considerations
References: <41BDA3D1.4040004@nokia.com>
In-Reply-To: <41BDA3D1.4040004@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Dec 2004 11:10:27.0427 (UTC)
	FILETIME=[841D3B30:01C4E1CD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: 7bit

As a followup of this thread for which I didn't get any comment. I 
noticed that MSRP includes the following text section 12:

    MSRP was designed to be only minimally extensible.  New MSRP Methods,
    Headers, and status codes can be defined in standards track RFCs.
    There is no registry of headers, methods, or status codes, since the
    number of new elements and total extensions is expected to be very
    small.  MSRP does not contain a version number or any negotiation
    mechanism to require or discover new features.  If a
    non-interoperable update or extension occurs in the future, it will
    be treated as a new protocol, and must describe how its use will be
    signaled.


It seems that the justification for not having an IANA registy of MSRP 
parameters is because MSRP is desienged to minimally extensible. It 
occurs to me that this justification seems a bit weak. We have seen so 
many protocols that started with this minimalistic approach and end up 
in being a highly extensible protocol (and I wouldn't mention examples 
here). MSRP already includes some rudimentary capabilities support (501 
Method not allowed, 415 MIME type not supported).

I also see that the IANA registration serves a two-fold purpose: on one 
side it avoids the clash of new MSRP parameters when they are defined; 
on the other side serves as a tracker of MSRP methods, headers and 
status codes. I see both very valuable for implementations, and I would 
encourage you to reconsider this decision prior to publish these drafts 
as RFCs.

Having said that, the MSRP relays draft needs a bit of clean-up in this 
area:
- It mentions the 423 "Interval Out-of-Bounds" response, but it is never 
properly defined.
- It mentions Min-Expires and Max-Expires headers, but they are not 
defined elsewhere either.

An IANA considerations section will help to kee track of those MSRP 
parameters, and identify whether they are errors or headers.

Regards,

           Miguel


Miguel Garcia wrote:

> About MSRP and the IANA considerations: I noticed that MSRP does not 
> register any method, header, response code, etc. Then, MSRP relays says 
> in section 9 that there are no new requirements to IANA:
> 
> Isn't this a bit mess without such registry? I would expect that MSRP 
> follows a similar policy than SIP. I would expect MSRP to open a new 
> MSRP registry with sub-registries for methods, headers, responses, etc.
> 
> Let's take MSRP-Relays. However, at least I have detected quite a few 
> new "things" to be registered with IANA. Essentially, everything 
> described under Section 4, "Overview of New Protocol Elements"
> 
> - New method: AUTH
> 
> - New headers: Use-Path, Authorization, WWW-Authenticate, 
> Authentication-Info, Expires, Min-Expires, Max-Expires
> 
> - New response code: 423 Out-of-bounds
> 
> By the way: I am missing 401 Unauthorized from the above list in Section 4.
> 
> Don't you think it would be easier to establish a registry with all 
> those sub-registries?
> 
> Regards,
> 
>           Miguel
> 
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Tue Dec 14 07:08:16 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17344;
	Tue, 14 Dec 2004 07:08:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeBbY-0005yz-7G; Tue, 14 Dec 2004 07:16:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeBQL-0007QO-Nf; Tue, 14 Dec 2004 07:05:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeBLK-0006go-Ps
	for simple@megatron.ietf.org; Tue, 14 Dec 2004 06:59:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16490
	for <simple@ietf.org>; Tue, 14 Dec 2004 06:59:48 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeBTL-0005nK-Cw
	for simple@ietf.org; Tue, 14 Dec 2004 07:08:07 -0500
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBEBsbk01912; Tue, 14 Dec 2004 13:54:40 +0200 (EET)
X-Scanned: Tue, 14 Dec 2004 13:54:04 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iBEBs4D0030234;
	Tue, 14 Dec 2004 13:54:04 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks003.ntc.nokia.com 00MWbPyG; Tue, 14 Dec 2004 13:54:03 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBEBrtD23461; Tue, 14 Dec 2004 13:53:55 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 14 Dec 2004 13:53:50 +0200
Message-ID: <41BED44C.3030409@nokia.com>
Date: Tue, 14 Dec 2004 13:53:48 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Cullen Jennings <fluffy@cisco.com>,
        Rohan Mahy <rohan@ekabal.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Dec 2004 11:53:50.0160 (UTC)
	FILETIME=[9376C500:01C4E1D3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>
Subject: [Simple] MSRP: Report-Failure partial
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit

Hi:

I am trying to understand the concise procedures that affect the 
Report-Failure: partial in MSRP, and I think I am missing something.

On reading the MSRP draft I found contradictory text:

- Second paragraph on 7.1.3 says:

    If the endpoint receives a SEND request with a Report-Failure header
    field ...  "partial", it MUST NOT send a transaction response to the
    request, but SHOULD send an appropriate non-200 class response a
    failure occurs.

So I understand that "partial" means "don't send 200, but send any other 
response".

- Section 7.3 says:

    When the
    request is received, the To-Path will have exactly one URL, which
    MUST map to an existing session that is associated with the
    connection on which the request arrived.  If this is not true, and
    the request contained a Report-Failure header value of "no" or
    "partial", then the receiver SHOULD quietly ignore the request.  If
    the Report-Failure header is not present, or had a value of "yes",
    then the receiver MUST return a 481 response.

Here the text says that "partial" means don't send a 481 response, which 
is obviously in contradiction with 7.1.3.

- Section 7.3.1 then says.

    If the SEND request contained a Content-Type header field indicating
    an unsupported MIME type, the receiver SHOULD send a 415 response or
    failure report, as appropriate for the Report-Failure header field
    value.

That is misleading me in another aspect: by reading the above text I may 
think that the Report-Failure header field value determines whether and 
endpoint sends failure responses or REPORT requests. So one could think 
that "Report-Failure: yes" means send REPORt requests rather than 
failure responses, whereas "Report-Failure: no" means the opposite. I 
believe this is not the intention, right?

So is this something that can be further clarified in the document?

Regards,


         Miguel



-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Tue Dec 14 08:15:18 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23101;
	Tue, 14 Dec 2004 08:15:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeCeO-00082W-Oi; Tue, 14 Dec 2004 08:23:37 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeCUT-0002aH-J0; Tue, 14 Dec 2004 08:13:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeCSE-0001wu-GE; Tue, 14 Dec 2004 08:11:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22781;
	Tue, 14 Dec 2004 08:11:01 -0500 (EST)
Received: from voyager.coretrek.no ([212.33.142.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeCa5-0007vH-4Y; Tue, 14 Dec 2004 08:19:20 -0500
Received: from localhost (localhost [127.0.0.1])
	by voyager.coretrek.no (Postfix) with ESMTP
	id BE61FA956E; Tue, 14 Dec 2004 14:10:17 +0100 (CET)
Received: from [192.168.1.67] (unknown [82.196.203.62])
	by voyager.coretrek.no (Postfix) with ESMTP
	id 35D6FA956A; Tue, 14 Dec 2004 14:10:13 +0100 (CET)
In-Reply-To: <41BE8ED0.9090303@nokia.com>
References: <41BE743B.8040003@cisco.com> <41BE8ED0.9090303@nokia.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <77CC5BAC-4DD1-11D9-8A90-000D93C60BA0@telio.no>
Content-Transfer-Encoding: 7bit
From: Hisham Khartabil <hisham.khartabil@telio.no>
Subject: Re: [Simple] Usage of substitution groups
	in	draft-ietf-geopriv-common-policy
Date: Tue, 14 Dec 2004 14:10:03 +0100
To: Jari Urpalainen <jari.urpalainen@nokia.com>
X-Mailer: Apple Mail (2.619)
X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1)
X-Spam-Score: 2.0 (++)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, 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
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit


On Dec 14, 2004, at 7:57 AM, Jari Urpalainen wrote:

> ext Jonathan Rosenberg wrote:
>
>> Folks,
>>
>> In several of the simple and geopriv specifications, we are making 
>> use of XML substitution groups as the mechanism for document 
>> extensibility. These include draft-ietf-geopriv-common-policy, which 
>> is extended by draft-ietf-simple-presence-rules.
>>
>> However, it appears that substitution groups introduce some 
>> limitations. Most important amongst them is that, in order to be 
>> validated against the schema for the baseline document, the entity 
>> doing the validation must be aware of the schemas for all namespaces 
>> for elements that are part of the substitution group. This doesn't 
>> work well in cases where we expect the entity creating the document 
>> to be making use of extensions that the entity doing the validation 
>> isn't going to be aware of (and shouldn't need to be).
>>
>> This is particularly problematic for 
>> draft-ietf-simple-presence-rules, where we expect to use xcap to 
>> manipulate the documents. The xcap server needs to be able to 
>> validate the document according to the baseline schema, but it should 
>> not be required to know about all of the extensions that we might see 
>> in order to process the document. Right now, it would have to.
>>
>> As a result, I'd suggest that draft-ietf-geopriv-common-policy make 
>> use of the <any> constructs for defining extensibility, rather than 
>> substitution groups.
>>
>> Comments?
>>
>> -Jonathan R.
>>
> Let's say you add a new extension e.g. <provide-dispatcher> 
> transformation onto the presence rules. If you'll use <any> constraint 
> in the schemas the server may validate the document although it may 
> not "understand" this new transformation and the client may think that 
> it will. However, if you'll use substitution groups and try to use 
> this new extension the server will not validate this extension unless 
> it has this new definition. So imo substitution groups provide much 
> more consistent behavior in this case.  If these rules are stored 
> within the xcap server the client can always query the server 
> capabilities (which lists namespaces that it understands).

As you say, the client can query server capabilities, so if the schema 
uses the <any> instead of substitution groups, then this REQUIRES the 
client to query first if it is critical to it that the server 
understands the extension. The difference is that when using <any>, the 
client will never know whether the server understands an extension or 
not unless it queries it. For substitution, the client will know since 
the server will not validate the XML document. Requiring the client to 
query server for its capabilities is not a bad thing. So I believe that 
<any> is sufficient enough.

Regards,
Hisham

>
> Of course there are situations where substitution groups don't 
> necessarily fit that well, i.e. they may be too restrictive. However, 
> I may have misunderstood where/how you'll want to use <any>...
> br,
> Jari
>
> _______________________________________________
> 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 Dec 14 10:11:03 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05855;
	Tue, 14 Dec 2004 10:11:03 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeESQ-0003jF-83; Tue, 14 Dec 2004 10:19:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeE5h-00077G-0z; Tue, 14 Dec 2004 09:55:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeDQb-0000q3-Fz; Tue, 14 Dec 2004 09:13:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28748;
	Tue, 14 Dec 2004 09:13:24 -0500 (EST)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeDYc-0001Uu-GE; Tue, 14 Dec 2004 09:21:43 -0500
Received: from razor.cs.columbia.edu
	(IDENT:fXzMdTLAb73IoprZrz3YcnIOSPOHCp6b@razor.cs.columbia.edu
	[128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBEEDITO029950;
	Tue, 14 Dec 2004 09:13:19 -0500 (EST)
Received: from [127.0.0.1] (IDENT:RitzfMfs+vJSQ1uuyxEjhpSNaiqbVtpy@localhost
	[127.0.0.1])
	by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBEEDHU3003953;
	Tue, 14 Dec 2004 09:13:17 -0500
Message-ID: <41BEF4FC.8080103@cs.columbia.edu>
Date: Tue, 14 Dec 2004 09:13:16 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Hisham Khartabil <hisham.khartabil@telio.no>
Subject: Re: [Simple] Usage of substitution
	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com> <41BE8ED0.9090303@nokia.com>
	<77CC5BAC-4DD1-11D9-8A90-000D93C60BA0@telio.no>
In-Reply-To: <77CC5BAC-4DD1-11D9-8A90-000D93C60BA0@telio.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0,
	Antispam-Data: 2004.12.13.53
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0,
	__SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>,
        Jari Urpalainen <jari.urpalainen@nokia.com>,
        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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit

To add to this, agreeing: At least some of the XML schema verifiers give 
up after the first error. Thus, you might end up with repeatedly trying 
to determine what extensions are actually supported, by removing one 
offending part after the other. Schema validation doesn't strike me as a 
particularly useful approach to discovering server capabilities (and I 
don't think it's really designed for this).


Hisham Khartabil wrote:


> 
> As you say, the client can query server capabilities, so if the schema 
> uses the <any> instead of substitution groups, then this REQUIRES the 
> client to query first if it is critical to it that the server 
> understands the extension. The difference is that when using <any>, the 
> client will never know whether the server understands an extension or 
> not unless it queries it. For substitution, the client will know since 
> the server will not validate the XML document. Requiring the client to 
> query server for its capabilities is not a bad thing. So I believe that 
> <any> is sufficient enough.

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


From simple-bounces@ietf.org  Tue Dec 14 10:32:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09616;
	Tue, 14 Dec 2004 10:32:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeEnT-0004U9-9v; Tue, 14 Dec 2004 10:41:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeERu-00019y-JD; Tue, 14 Dec 2004 10:18:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeEGt-0003fA-49; Tue, 14 Dec 2004 10:07:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05356;
	Tue, 14 Dec 2004 10:07:25 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeEOr-0003d1-Tb; Tue, 14 Dec 2004 10:15:45 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 14 Dec 2004 08:13:22 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBEF6kVw005399;
	Tue, 14 Dec 2004 07:06:46 -0800 (PST)
Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id ANR60709; Tue, 14 Dec 2004 10:06:47 -0500 (EST)
Message-ID: <41BF0186.3050507@cisco.com>
Date: Tue, 14 Dec 2004 10:06:46 -0500
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: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Simple] Usage of substitution
	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com> <41BE8ED0.9090303@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.0 (++)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, 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
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit

Jari,

My concern is that I may sometime find myself to be an AOL subscriber 
for presence. (Perhaps because that is the only place some of my buddies 
are capable of accessing.)

I don't want to be dependent on AOL to install support for a new 
presence entity before I can begin to use it.

	Paul

Jari Urpalainen wrote:
> 
> Let's say you add a new extension e.g. <provide-dispatcher> 
> transformation onto the presence rules. If you'll use <any> constraint 
> in the schemas the server may validate the document although it may not 
> "understand" this new transformation and the client may think that it 
> will. However, if you'll use substitution groups and try to use this new 
> extension the server will not validate this extension unless it has this 
> new definition. So imo substitution groups provide much more consistent 
> behavior in this case.  If these rules are stored within the xcap server 
> the client can always query the server capabilities (which lists 
> namespaces that it understands).
> 
> Of course there are situations where substitution groups don't 
> necessarily fit that well, i.e. they may be too restrictive. However, I 
> may have misunderstood where/how you'll want to use <any>...
> br,
> Jari
> 
> _______________________________________________
> 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 Dec 15 03:43:24 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12011;
	Wed, 15 Dec 2004 03:43:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeUt0-00071L-Pt; Wed, 15 Dec 2004 03:51:55 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeUgb-0003dZ-Hk; Wed, 15 Dec 2004 03:39:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeUbe-00033W-Fh
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 03:33:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11523
	for <simple@ietf.org>; Wed, 15 Dec 2004 03:33:56 -0500 (EST)
Received: from [203.199.83.245] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CeUjn-0006oW-Vb
	for simple@ietf.org; Wed, 15 Dec 2004 03:42:26 -0500
Received: (qmail 28407 invoked by uid 510); 15 Dec 2004 08:34:41 -0000
Date: 15 Dec 2004 08:34:41 -0000
Message-ID: <20041215083441.28406.qmail@mailweb33.rediffmail.com>
Received: from unknown (203.126.136.220) by rediffmail.com via HTTP;
	15 dec 2004 08:34:41 -0000
MIME-Version: 1.0
From: "Anir  P" <anip_2010@rediffmail.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
X-Spam-Score: 4.0 (++++)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>,
        Jari Urpalainen <jari.urpalainen@nokia.com>,
        Simple WG <simple@ietf.org>
Subject: [Simple] XML parsing
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Anir  P <anip_2010@rediffmail.com>
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="===============0422442031=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

 This is a multipart mime message


--===============0422442031==
Content-type: multipart/alternative;
	boundary="Next_1103099681---0-203.199.83.245-28402"

 This is a multipart mime message


--Next_1103099681---0-203.199.83.245-28402
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi=0AIs there any XML parser freely available which I can use for SIMPLE im=
plementation. =0A=0AAny information regarding this highly appriciated.=0A=
=0AThanks=0AKamal=0A
--Next_1103099681---0-203.199.83.245-28402
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0AHi<BR>=0AIs there any XML parser freely available which I can use for=
 SIMPLE implementation. <BR>=0A<BR>=0AAny information regarding this highly=
 appriciated.<BR>=0A<BR>=0AThanks<BR>=0AKamal<BR>=0A=0A</P>=0A<br><br>=0A<A=
 target=3D"_blank" HREF=3D"http://clients.rediff.com/signature/track_sig.as=
p"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.redi=
ffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1103099681---0-203.199.83.245-28402--



--===============0422442031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0422442031==--




From simple-bounces@ietf.org  Wed Dec 15 07:28:45 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26196;
	Wed, 15 Dec 2004 07:28:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeYP6-00043s-Um; Wed, 15 Dec 2004 07:37:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeYCL-0003Tv-9U; Wed, 15 Dec 2004 07:24:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeY89-0002f6-KI; Wed, 15 Dec 2004 07:19:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25751;
	Wed, 15 Dec 2004 07:19:44 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeYGM-0003sU-Vc; Wed, 15 Dec 2004 07:28:15 -0500
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBFCJXF15363; Wed, 15 Dec 2004 14:19:34 +0200 (EET)
X-Scanned: Wed, 15 Dec 2004 14:24:29 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iBFCOTJ6006304;
	Wed, 15 Dec 2004 14:24:29 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 003Vg6uE; Wed, 15 Dec 2004 14:24:26 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBFCJ9302723; Wed, 15 Dec 2004 14:19:09 +0200 (EET)
Received: from kusti.research.nokia.com ([172.21.56.13]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 15 Dec 2004 14:17:38 +0200
Received: from [172.21.50.105] (xitami.research.nokia.com [172.21.50.105])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 4998F93B75; Wed, 15 Dec 2004 14:17:37 +0200 (EET)
Message-ID: <41C02A85.3050608@nokia.com>
Date: Wed, 15 Dec 2004 14:13:57 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Simple] Usage of substitution
	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com> <41BE8ED0.9090303@nokia.com>
	<41BF0186.3050507@cisco.com>
In-Reply-To: <41BF0186.3050507@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2004 12:17:38.0472 (UTC)
	FILETIME=[1137A280:01C4E2A0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, 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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit

ext Paul Kyzivat wrote:

> Jari,
>
> My concern is that I may sometime find myself to be an AOL subscriber 
> for presence. (Perhaps because that is the only place some of my 
> buddies are capable of accessing.)
>
> I don't want to be dependent on AOL to install support for a new 
> presence entity before I can begin to use it.
>
>     Paul

If it so that the client only needs to "understand" this extension I'll 
agree but if you need also the server to "understand" it then I may 
disagree.

My point was and is that we'll have to select case-by-case the extension 
model. I am assuming that we all want unambiguous and consistent 
semantics. Looking from the schema validation pov we have at least these 
possibilities:
1. using <any> with ##any or ##other namespace and with processContents 
"lax", "skip" or "strict".
2. using abstract elements with substitionGroups
The latter is the most restrictive one (and of course you'll need the 
new definitions) although there's not a big difference in that respect 
with <any> with "strict".

Speaking about the presence entity we'll get onto pidf, where the 
extension is based on <any>, "##other" and "lax" model. Let's say we are 
using rpid extension. So if the validator has rpid schema and the 
instance document uses e.g. <privacy> extension but instead of the 
requirement (<status>) puts that onto <tuple>. The validator can check 
that <privacy> is well formed and valid according to rpid schema but it 
doesn't know where it belongs within the pidf and will then validate the 
document. However, if substitutionGroup had been used it would have 
explicitly forbidden this. So my point is that abstract types with 
substitutionGroups are very explicit and imo a good way to point the 
extension places in xml documents. Using <any> introduces vagueness to 
the validation process that I would prefer to avoid. 

So to summarize my preference is abstract elements with 
substitutionGroups in this context. However, if there's really a need 
e.g. for the case where the clients can use the extension before the 
server is being updated then there is not any other alternative than to 
use <any>.

So then back to the reality, are we looking in presence authorization 
e.g. something like ?

<xs:element name="provide-extension" substitutionGroup="cr:transformation">
  ||<xs:complexType>
    <xs:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded">
  ||</xs:complexType>
</xs:element>

br,
Jari




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


From simple-bounces@ietf.org  Wed Dec 15 08:00:17 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27936;
	Wed, 15 Dec 2004 08:00:17 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeYtc-0004t7-0Q; Wed, 15 Dec 2004 08:08:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeYfF-0001Qr-9p; Wed, 15 Dec 2004 07:53:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeYb9-0000YU-Qx; Wed, 15 Dec 2004 07:49:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27286;
	Wed, 15 Dec 2004 07:49:42 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeYjM-0004Vq-Kp; Wed, 15 Dec 2004 07:58:14 -0500
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
	iBFCnSF05872; Wed, 15 Dec 2004 14:49:28 +0200 (EET)
X-Scanned: Wed, 15 Dec 2004 14:47:20 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iBFClKeR008869;
	Wed, 15 Dec 2004 14:47:20 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00tLAmcG; Wed, 15 Dec 2004 14:47:17 EET
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBFClBD28509; Wed, 15 Dec 2004 14:47:11 +0200 (EET)
Received: from kusti.research.nokia.com ([172.21.56.13]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 15 Dec 2004 14:46:48 +0200
Received: from [172.21.50.105] (xitami.research.nokia.com [172.21.50.105])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id DFA9693B6A; Wed, 15 Dec 2004 14:46:47 +0200 (EET)
Message-ID: <41C0315C.2080908@nokia.com>
Date: Wed, 15 Dec 2004 14:43:08 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anir P <anip_2010@rediffmail.com>
References: <20041215083441.28406.qmail@mailweb33.rediffmail.com>
In-Reply-To: <20041215083441.28406.qmail@mailweb33.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2004 12:46:48.0223 (UTC)
	FILETIME=[242672F0:01C4E2A4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Simple WG <simple@ietf.org>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: [Simple] Re: XML parsing
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit

ext Anir P wrote:

> Hi
> Is there any XML parser freely available which I can use for SIMPLE 
> implementation.
>
> Any information regarding this highly appriciated.
>
> Thanks
> Kamal
>
There are many freely available xml parsers available, I have mostly 
used libxml2 and Xerces. However, the proper answer to your question 
depends a lot of your implementation environment, i.e. your operation 
system and what languages are you using. Anyway, if your environment 
matches with what libxml2 provides/needs I can really recommend it. 
Although it is written with C it has quite so many other language 
bindings (C++, python etc.). I have also used Xerces (C++ and Java) for 
Schema validation.

br,
Jari

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


From simple-bounces@ietf.org  Wed Dec 15 09:09:25 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02230;
	Wed, 15 Dec 2004 09:09:25 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeZyY-0006U7-KD; Wed, 15 Dec 2004 09:17:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeZfT-00070D-6s; Wed, 15 Dec 2004 08:58:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeZeS-0006bL-Fe
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 08:57:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01649
	for <simple@ietf.org>; Wed, 15 Dec 2004 08:57:10 -0500 (EST)
Received: from [203.199.83.135] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CeZmf-0006Cn-RD
	for simple@ietf.org; Wed, 15 Dec 2004 09:05:43 -0500
Received: (qmail 25488 invoked by uid 510); 15 Dec 2004 13:57:57 -0000
Date: 15 Dec 2004 13:57:57 -0000
Message-ID: <20041215135757.25487.qmail@webmail45.rediffmail.com>
Received: from unknown (203.126.136.220) by rediffmail.com via HTTP;
	15 dec 2004 13:57:57 -0000
MIME-Version: 1.0
From: "Anir  P" <anip_2010@rediffmail.com>
To: "Jari Urpalainen" <jari.urpalainen@nokia.com>
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Simple WG <simple@ietf.org>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: [Simple] XML parsing
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Anir  P <anip_2010@rediffmail.com>
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="===============2021506477=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

 This is a multipart mime message


--===============2021506477==
Content-type: multipart/alternative;
	boundary="Next_1103119077---0-203.199.83.135-25485"

 This is a multipart mime message


--Next_1103119077---0-203.199.83.135-25485
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

 =A0=0AHi=0AI want a generic C XML parser source code which can parse XML b=
ody (including schema). The library form will be specifi to a platform. Is =
there any source code available which can do XML (including schema) decodin=
g, encoding etc.=0A=0ARegards=0A=0A=0AOn Wed, 15 Dec 2004 Jari Urpalainen w=
rote :=0A>ext Anir P wrote:=0A>=0A>>Hi=0A>>Is there any XML parser freely a=
vailable which I can use for SIMPLE implementation.=0A>>=0A>>Any informatio=
n regarding this highly appriciated.=0A>>=0A>>Thanks=0A>>=0A>There are many=
 freely available xml parsers available, I have mostly used libxml2 and Xer=
ces. However, the proper answer to your question depends a lot of your impl=
ementation environment, i.e. your operation system and what languages are y=
ou using. Anyway, if your environment matches with what libxml2 provides/ne=
eds I can really recommend it. Although it is written with C it has quite s=
o many other language bindings (C++, python etc.). I have also used Xerces =
(C++ and Java) for Schema validation.=0A>=0A>br,=0A>Jari=0A
--Next_1103119077---0-203.199.83.135-25485
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0A&nbsp; <BR>=0AHi<BR>=0AI want a generic C XML parser source code whic=
h can parse XML body (including schema). The library form will be specifi t=
o a platform. Is there any source code available which can do XML (includin=
g schema) decoding, encoding etc.<BR>=0A<BR>=0ARegards<BR>=0A<BR>=0A<BR>=0A=
On Wed, 15 Dec 2004 Jari Urpalainen wrote :<BR>=0A&gt;ext Anir P wrote:<BR>=
=0A&gt;<BR>=0A&gt;&gt;Hi<BR>=0A&gt;&gt;Is there any XML parser freely avail=
able which I can use for SIMPLE implementation.<BR>=0A&gt;&gt;<BR>=0A&gt;&g=
t;Any information regarding this highly appriciated.<BR>=0A&gt;&gt;<BR>=0A&=
gt;&gt;Thanks<BR>=0A&gt;&gt;<BR>=0A&gt;There are many freely available xml =
parsers available, I have mostly used libxml2 and Xerces. However, the prop=
er answer to your question depends a lot of your implementation environment=
, i.e. your operation system and what languages are you using. Anyway, if y=
our environment matches with what libxml2 provides/needs I can really recom=
mend it. Although it is written with C it has quite so many other language =
bindings (C++, python etc.). I have also used Xerces (C++ and Java) for Sch=
ema validation.<BR>=0A&gt;<BR>=0A&gt;br,<BR>=0A&gt;Jari<BR>=0A=0A</P>=0A<br=
><br>=0A<A target=3D"_blank" HREF=3D"http://clients.rediff.com/signature/tr=
ack_sig.asp"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx.cg=
i/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0></a=
>=0A
--Next_1103119077---0-203.199.83.135-25485--



--===============2021506477==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============2021506477==--




From simple-bounces@ietf.org  Wed Dec 15 09:57:59 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05530;
	Wed, 15 Dec 2004 09:57:59 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeajY-0007mJ-QW; Wed, 15 Dec 2004 10:06:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeaHq-0007Mw-Lr; Wed, 15 Dec 2004 09:37:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cea8p-0005GL-TK
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 09:28:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03512
	for <simple@ietf.org>; Wed, 15 Dec 2004 09:28:33 -0500 (EST)
Received: from smtp7.clb.oleane.net ([213.56.31.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeaH4-0006x8-O9
	for simple@ietf.org; Wed, 15 Dec 2004 09:37:07 -0500
Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be
	forged)) by smtp7.clb.oleane.net with ESMTP id iBFERe3P017135
	for <simple@ietf.org>; Wed, 15 Dec 2004 15:28:03 +0100
Message-Id: <200412151428.iBFERe3P017135@smtp7.clb.oleane.net>
From: "Gunter" <g.palmer@dial.oleane.com>
To: <simple@ietf.org>
Date: Wed, 15 Dec 2004 15:28:01 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTiskhFhvjqrXUNSkyXgxpVfFb81A==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Subject: [Simple] WiMAX Summit'05 - Paris - France
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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="===============1526089623=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221

This is a multi-part message in MIME format.

--===============1526089623==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_03FE_01C4E2BA.AA45C4B0"

This is a multi-part message in MIME format.

------=_NextPart_000_03FE_01C4E2BA.AA45C4B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

. What is the business model for WiMAX? 
. What do we learn from earlier deployments? 
. What about the future extensions of the standard? 
. How is addressed the interoperability challenge? 

These questions, among others, will be addressed during the second edition
of the WiMAX Summit to be organised in Paris next 5-8 April 2005.

 

Get all details at:

 <http://www.upperside.fr/wimax05/wimax2005intro.htm>
http://www.upperside.fr/wimax05/wimax2005intro.htm

 

 


------=_NextPart_000_03FE_01C4E2BA.AA45C4B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR 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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D1 face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:9.0pt;font-family:Arial'>&#8226; =
</span></font></b></strong><font
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'>What
is the <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>business
model</span></font></b></strong> for WiMAX? <br>
<strong><b><font face=3DArial><span style=3D'font-family:Arial'>&#8226; =
</span></font></b></strong>What
do we learn from <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>earlier
deployments</span></font></b></strong>? <br>
<strong><b><font face=3DArial><span style=3D'font-family:Arial'>&#8226; =
</span></font></b></strong>What
about the <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>future
extensions</span></font></b></strong> of the standard? <br>
<strong><b><font face=3DArial><span style=3D'font-family:Arial'>&#8226; =
</span></font></b></strong>How
is addressed the <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>interoperability</span></font></b></strong>
challenge? <br>
<br>
These questions, among others, will be addressed during the second =
edition of
the WiMAX Summit to be organised in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Paris</st1:City></st1:place>
next 5-8 April 2005.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'>Get all details =
at:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;
font-family:Arial'><a =
href=3D"http://www.upperside.fr/wimax05/wimax2005intro.htm"
title=3D"http://www.upperside.fr/wimax05/wimax2005intro.htm"><span =
lang=3DEN-GB><span
title=3D"http://www.upperside.fr/wimax05/wimax2005intro.htm">http://www.u=
pperside.fr/wimax05/wimax2005intro.htm</span></span></a></span></font><fo=
nt
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'><o:p></o:p></span></font></p>=


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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_03FE_01C4E2BA.AA45C4B0--



--===============1526089623==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1526089623==--




From simple-bounces@ietf.org  Wed Dec 15 10:20:13 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07666;
	Wed, 15 Dec 2004 10:20:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ceb54-0008Nq-Uk; Wed, 15 Dec 2004 10:28:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeaiG-0004SK-AS; Wed, 15 Dec 2004 10:05:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeaeZ-0006iz-Tv; Wed, 15 Dec 2004 10:01:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05827;
	Wed, 15 Dec 2004 10:01:21 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ceamn-0007sn-9c; Wed, 15 Dec 2004 10:09:54 -0500
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBFF0oF05090; Wed, 15 Dec 2004 17:00:51 +0200 (EET)
X-Scanned: Wed, 15 Dec 2004 16:56:11 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBFEuBbR008024;
	Wed, 15 Dec 2004 16:56:11 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00tVQrwN; Wed, 15 Dec 2004 16:55:08 EET
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBFEt2D10175; Wed, 15 Dec 2004 16:55:02 +0200 (EET)
Received: from kusti.research.nokia.com ([172.21.56.13]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 15 Dec 2004 16:54:58 +0200
Received: from [172.21.50.105] (xitami.research.nokia.com [172.21.50.105])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id A9FC693B79; Wed, 15 Dec 2004 16:54:57 +0200 (EET)
Message-ID: <41C04F65.4070209@nokia.com>
Date: Wed, 15 Dec 2004 16:51:17 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anir P <anip_2010@rediffmail.com>
References: <20041215135757.25487.qmail@webmail45.rediffmail.com>
In-Reply-To: <20041215135757.25487.qmail@webmail45.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2004 14:54:58.0270 (UTC)
	FILETIME=[0BC67FE0:01C4E2B6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Simple WG <simple@ietf.org>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: [Simple] Re: XML parsing
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit

ext Anir P wrote:

>  
> Hi
> I want a generic C XML parser source code which can parse XML body 
> (including schema). The library form will be specifi to a platform. Is 
> there any source code available which can do XML (including schema) 
> decoding, encoding etc.
>
> Regards
>
Look at http://www.xmlsoft.org/. It can also handle some xml Schema 
validation. Since I previously tried this validation it seems to have 
been improved quite a lot as it could flawlessly validate e.g. rfc 3863 
examples. I'll have to run also some more complex examples, but even 
this looks promising.

br,
Jari

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


From simple-bounces@ietf.org  Wed Dec 15 10:37:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09502;
	Wed, 15 Dec 2004 10:37:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CebM4-0000SU-6n; Wed, 15 Dec 2004 10:46:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ceb44-0007WZ-Hl; Wed, 15 Dec 2004 10:27:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ceazv-0006AI-PO; Wed, 15 Dec 2004 10:23:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08061;
	Wed, 15 Dec 2004 10:23:25 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ceb8A-0008Vb-R2; Wed, 15 Dec 2004 10:31:59 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 15 Dec 2004 08:29:37 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBFFMgMI009990;
	Wed, 15 Dec 2004 07:22:45 -0800 (PST)
Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id ANS43417; Wed, 15 Dec 2004 10:22:48 -0500 (EST)
Message-ID: <41C056C8.5070400@cisco.com>
Date: Wed, 15 Dec 2004 10:22:48 -0500
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: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Simple] Usage of substitution
	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com> <41BE8ED0.9090303@nokia.com>
	<41BF0186.3050507@cisco.com> <41C02A85.3050608@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, 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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit



Jari Urpalainen wrote:
> ext Paul Kyzivat wrote:
> 
>> Jari,
>>
>> My concern is that I may sometime find myself to be an AOL subscriber 
>> for presence. (Perhaps because that is the only place some of my 
>> buddies are capable of accessing.)
>>
>> I don't want to be dependent on AOL to install support for a new 
>> presence entity before I can begin to use it.
>>
>>     Paul
> 
> 
> If it so that the client only needs to "understand" this extension I'll 
> agree but if you need also the server to "understand" it then I may 
> disagree.

Yes, the distinction is key.

> My point was and is that we'll have to select case-by-case the extension 
> model. I am assuming that we all want unambiguous and consistent 
> semantics. Looking from the schema validation pov we have at least these 
> possibilities:
> 1. using <any> with ##any or ##other namespace and with processContents 
> "lax", "skip" or "strict".
> 2. using abstract elements with substitionGroups
> The latter is the most restrictive one (and of course you'll need the 
> new definitions) although there's not a big difference in that respect 
> with <any> with "strict".

I think the problem is that we want the best of both, and that doesn't 
seem to be possible. What I mean is:

- for those that don't understand it, we would like a treatment like 
<any> with lax or skip. (I don't know xml well enough to understand the 
difference between those.)

- for those that do understand the item, we would like it to be treated 
with the substitution group semantics.

At least I think that is what we would like for PIDF extensions. In many 
cases it is probably sufficient for the endpoints to understand the 
extensions they want and ignore the rest. And for the presence server to 
treat them generically without understanding them.

For sophisticated composition of presence documents a lack of 
understanding of an element will perhaps lead to less than perfect 
composition. But the decoupling of client evolution from server 
evolution is sufficiently important that composition needs to be 
designed to tolerate this.

> Speaking about the presence entity we'll get onto pidf, where the 
> extension is based on <any>, "##other" and "lax" model. Let's say we are 
> using rpid extension. So if the validator has rpid schema and the 
> instance document uses e.g. <privacy> extension but instead of the 
> requirement (<status>) puts that onto <tuple>. The validator can check 
> that <privacy> is well formed and valid according to rpid schema but it 
> doesn't know where it belongs within the pidf and will then validate the 
> document. However, if substitutionGroup had been used it would have 
> explicitly forbidden this.

Yes, this was the motivation to use substitution groups. But if the 
validator hasn't heard of <privacy> then validation fails even if it was 
used correctly.

With <any>, it will pass on the server, but hopefully the receiving 
client that does understand it will recognize that it is misplaced. But 
that recognition of being misplaced then can't be part of the formal 
validation logic, but must be hand coded.

 > So my point is that abstract types with
> substitutionGroups are very explicit and imo a good way to point the 
> extension places in xml documents. Using <any> introduces vagueness to 
> the validation process that I would prefer to avoid.

The tradeoff is better validation in the server, but constraint that you 
can't use a new feature until the server has been extended to support 
it. For presence I think this is a bad tradeoff.

> So to summarize my preference is abstract elements with 
> substitutionGroups in this context. However, if there's really a need 
> e.g. for the case where the clients can use the extension before the 
> server is being updated then there is not any other alternative than to 
> use <any>.

Sad. We need an extension mechanism different than what is available.

> So then back to the reality, are we looking in presence authorization 
> e.g. something like ?
> 
> <xs:element name="provide-extension" substitutionGroup="cr:transformation">
>  ||<xs:complexType>
>    <xs:any namespace="##other" processContents="lax" minOccurs="0" 
> maxOccurs="unbounded">
>  ||</xs:complexType>
> </xs:element>

Don't understand above.

	Paul

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


From simple-bounces@ietf.org  Wed Dec 15 11:50:15 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16089;
	Wed, 15 Dec 2004 11:50:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CecUE-0002G9-2b; Wed, 15 Dec 2004 11:58:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CecHq-0001o7-Tt; Wed, 15 Dec 2004 11:46:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CecEX-0000sw-Ie
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 11:42:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15498
	for <simple@ietf.org>; Wed, 15 Dec 2004 11:42:34 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CecMl-000247-LB
	for simple@ietf.org; Wed, 15 Dec 2004 11:51:10 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 15 Dec 2004 08:46:06 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBFGg1sv021436;
	Wed, 15 Dec 2004 08:42:01 -0800 (PST)
Received: from [10.32.131.131] ([10.32.131.131])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUT86164;
	Wed, 15 Dec 2004 08:42:00 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Tue, 14 Dec 2004 22:22:21 -0700
From: Cullen Jennings <fluffy@cisco.com>
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Ben Campbell <ben@nostrum.com>,
        Rohan Mahy <rohan@ekabal.com>, Cullen Jennings <fluffy@cisco.com>
Message-ID: <BDE5181D.1F9C5%fluffy@cisco.com>
In-Reply-To: <41BED44C.3030409@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>
Subject: [Simple] Re: MSRP: Report-Failure partial
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
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit


The goal of "partial" was to report errors except timeouts. The timeout
require the sending hop to run a timer and that receiving hop to send an
acknowledgement to stop the timer. Some systems don't want the overhead of
doing this so choose not to but still report other errors.

We may have the text messed up to describe this.

On 12/14/04 4:53 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:

> Hi:
> 
> I am trying to understand the concise procedures that affect the
> Report-Failure: partial in MSRP, and I think I am missing something.
> 
> On reading the MSRP draft I found contradictory text:
> 
> - Second paragraph on 7.1.3 says:
> 
>     If the endpoint receives a SEND request with a Report-Failure header
>     field ...  "partial", it MUST NOT send a transaction response to the
>     request, but SHOULD send an appropriate non-200 class response a
>     failure occurs.
> 
> So I understand that "partial" means "don't send 200, but send any other
> response".
> 
> - Section 7.3 says:
> 
>     When the
>     request is received, the To-Path will have exactly one URL, which
>     MUST map to an existing session that is associated with the
>     connection on which the request arrived.  If this is not true, and
>     the request contained a Report-Failure header value of "no" or
>     "partial", then the receiver SHOULD quietly ignore the request.  If
>     the Report-Failure header is not present, or had a value of "yes",
>     then the receiver MUST return a 481 response.
> 
> Here the text says that "partial" means don't send a 481 response, which
> is obviously in contradiction with 7.1.3.
> 
> - Section 7.3.1 then says.
> 
>     If the SEND request contained a Content-Type header field indicating
>     an unsupported MIME type, the receiver SHOULD send a 415 response or
>     failure report, as appropriate for the Report-Failure header field
>     value.
> 
> That is misleading me in another aspect: by reading the above text I may
> think that the Report-Failure header field value determines whether and
> endpoint sends failure responses or REPORT requests. So one could think
> that "Report-Failure: yes" means send REPORt requests rather than
> failure responses, whereas "Report-Failure: no" means the opposite. I
> believe this is not the intention, right?
> 
> So is this something that can be further clarified in the document?
> 
> Regards,
> 
> 
>          Miguel
> 
> 


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


From simple-bounces@ietf.org  Wed Dec 15 11:57:23 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16651;
	Wed, 15 Dec 2004 11:57:23 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cecb7-0002TG-VR; Wed, 15 Dec 2004 12:05:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CecHt-0001oP-GF; Wed, 15 Dec 2004 11:46:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CecEa-0000sy-5A
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 11:42:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15507
	for <simple@ietf.org>; Wed, 15 Dec 2004 11:42:37 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CecMo-000247-B9
	for simple@ietf.org; Wed, 15 Dec 2004 11:51:12 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-2.cisco.com with ESMTP; 15 Dec 2004 08:46:07 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBFGg0Vw005732;
	Wed, 15 Dec 2004 08:42:00 -0800 (PST)
Received: from [10.32.131.131] ([10.32.131.131])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUT86169;
	Wed, 15 Dec 2004 08:42:01 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Tue, 14 Dec 2004 22:33:29 -0700
From: Cullen Jennings <fluffy@cisco.com>
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Rohan Mahy <rohan@ekabal.com>,
        Ben Campbell <ben@nostrum.com>
Message-ID: <BDE51AB9.1F9C9%fluffy@cisco.com>
In-Reply-To: <41BDA3D1.4040004@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>
Subject: [Simple] Re: MSRP: IANA considerations
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
X-Spam-Score: 0.6 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit


Don't know what others think but I don't think a registry is needed for any
of this. If later on there is great need for it, we could add it later (like
we did for SIP). I don't care greatly but don't want to clog IAN que with
stuff not critical.



On 12/13/04 6:14 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:

> About MSRP and the IANA considerations: I noticed that MSRP does not
> register any method, header, response code, etc. Then, MSRP relays says
> in section 9 that there are no new requirements to IANA:
> 
> Isn't this a bit mess without such registry? I would expect that MSRP
> follows a similar policy than SIP. I would expect MSRP to open a new
> MSRP registry with sub-registries for methods, headers, responses, etc.
> 
> Let's take MSRP-Relays. However, at least I have detected quite a few
> new "things" to be registered with IANA. Essentially, everything
> described under Section 4, "Overview of New Protocol Elements"
> 
> - New method: AUTH
> 
> - New headers: Use-Path, Authorization, WWW-Authenticate,
> Authentication-Info, Expires, Min-Expires, Max-Expires
> 
> - New response code: 423 Out-of-bounds
> 
> By the way: I am missing 401 Unauthorized from the above list in Section 4.
> 
> Don't you think it would be easier to establish a registry with all
> those sub-registries?
> 
> Regards,
> 
>            Miguel
> 
> 


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


From simple-bounces@ietf.org  Wed Dec 15 11:59:30 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16790;
	Wed, 15 Dec 2004 11:59:30 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CecdA-0002We-H3; Wed, 15 Dec 2004 12:08:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CecHt-0001oU-Uj; Wed, 15 Dec 2004 11:46:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CecEb-0000t1-0H
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 11:42:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15515
	for <simple@ietf.org>; Wed, 15 Dec 2004 11:42:38 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CecMp-00024B-20
	for simple@ietf.org; Wed, 15 Dec 2004 11:51:13 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 15 Dec 2004 09:48:49 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBFGg1t1021436;
	Wed, 15 Dec 2004 08:42:05 -0800 (PST)
Received: from [10.32.131.131] ([10.32.131.131])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUT86166;
	Wed, 15 Dec 2004 08:42:00 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Tue, 14 Dec 2004 22:26:25 -0700
From: Cullen Jennings <fluffy@cisco.com>
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Ben Campbell <ben@nostrum.com>,
        Rohan Mahy <rohan@ekabal.com>
Message-ID: <BDE51911.1F9C8%fluffy@cisco.com>
In-Reply-To: <41BD9BF5.3040109@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.7 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>
Subject: [Simple] Re: MSRP URLs
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
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit


Ooops - need to fix.

Any particular reason to have the // ?


On 12/13/04 5:41 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:

> A question about MSRP URLs.
> 
> I noticed that the MSRP draft defines URLs to be of the following format:
> 
> msrp://alice.example.com:3092/32dk;tcp
> 
> whereas the MSRP-relays draft don't uses the "//". For instance:
> 
> msrp:a.example.com:1234/agic456;tcp
> 
> and
> 
> msrps:alice@intra.example.com
> 
> So do MSRP URLs contain "//" or not? If yes, how to accommodate
> usernames in the URL?
> 
> I guess one or the other draft have to change something...
> 
> Regards,
> 
>        Miguel


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


From simple-bounces@ietf.org  Wed Dec 15 14:13:03 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29329;
	Wed, 15 Dec 2004 14:13:03 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeeiP-00070M-QD; Wed, 15 Dec 2004 14:21:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeeLR-0002Um-Vv; Wed, 15 Dec 2004 13:57:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeeHF-00013k-7h
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 13:53:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27911
	for <simple@ietf.org>; Wed, 15 Dec 2004 13:53:31 -0500 (EST)
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeePW-0006Sr-Bn
	for simple@ietf.org; Wed, 15 Dec 2004 14:02:06 -0500
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	iBFIm0eD002177; Wed, 15 Dec 2004 10:48:00 -0800 (PST)
Received: from [10.30.1.143] (vpn-10-50-0-135.qualcomm.com [10.50.0.135])
	by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	iBFIluba011179; Wed, 15 Dec 2004 10:47:58 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p0620070abde636fd1d50@[10.30.1.143]>
In-Reply-To: <BDE51911.1F9C8%fluffy@cisco.com>
References: <BDE51911.1F9C8%fluffy@cisco.com>
Date: Wed, 15 Dec 2004 10:47:55 -0800
To: Cullen Jennings <fluffy@cisco.com>,
        Miguel Garcia <Miguel.An.Garcia@nokia.com>,
        Ben Campbell <ben@nostrum.com>, Rohan Mahy <rohan@ekabal.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: [Simple] Re: MSRP URLs
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: "simple@ietf.org" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

If the URI scheme is treating the string "alice.example.com:3092"
as an authority component, it is required.  Please see
draft-fielding-rfc2396bis,  section 3.2.

			regards,
				Ted

At 10:26 PM -0700 12/14/04, Cullen Jennings wrote:
>Ooops - need to fix.
>
>Any particular reason to have the // ?
>
>
>On 12/13/04 5:41 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:
>
>>  A question about MSRP URLs.
>>
>>  I noticed that the MSRP draft defines URLs to be of the following format:
>>
>>  msrp://alice.example.com:3092/32dk;tcp
>>
>>  whereas the MSRP-relays draft don't uses the "//". For instance:
>>
>>  msrp:a.example.com:1234/agic456;tcp
>>
>>  and
>>
>>  msrps:alice@intra.example.com
>>
>>  So do MSRP URLs contain "//" or not? If yes, how to accommodate
>>  usernames in the URL?
>>
>>  I guess one or the other draft have to change something...
>>
>>  Regards,
>>
>>         Miguel
>
>
>_______________________________________________
>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 Dec 15 14:50:51 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02693;
	Wed, 15 Dec 2004 14:50:51 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CefJ0-0007yP-Cg; Wed, 15 Dec 2004 14:59:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cef34-0003iz-Nr; Wed, 15 Dec 2004 14:42:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceeyc-0002uM-2x
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 14:38:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01807
	for <simple@ietf.org>; Wed, 15 Dec 2004 14:38:20 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cef6s-0007iC-Oc
	for simple@ietf.org; Wed, 15 Dec 2004 14:46:56 -0500
Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net
	[209.30.33.13]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBFJbDf3069017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Dec 2004 13:37:15 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <41C09268.9030601@nostrum.com>
Date: Wed, 15 Dec 2004 13:37:12 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Simple] Re: MSRP URLs
References: <BD9538F2.1522C%fluffy@cisco.com>
In-Reply-To: <BD9538F2.1522C%fluffy@cisco.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>,
        "simple@ietf.org" <simple@ietf.org>, rohan@cisco.com
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit

Cullen Jennings wrote:

> My read is that the text "compared numerically" was meant to imply 
> that 1080:0:0:0:8:800:200C:417A does match 1080::8:800:200C:417A - we 
> should clarify
>

Of *course* they mean the same thing. One is just syntactic sugar for 
the other one. Go ahead and put in a non-normative clarification, as it 
seems to be causing confusion...

/a

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


From simple-bounces@ietf.org  Wed Dec 15 15:07:15 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04020;
	Wed, 15 Dec 2004 15:07:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CefYr-0008R8-90; Wed, 15 Dec 2004 15:15:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CefKw-00016f-4j; Wed, 15 Dec 2004 15:01:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CefBz-0005I4-Mb
	for simple@megatron.ietf.org; Wed, 15 Dec 2004 14:52:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02886
	for <simple@ietf.org>; Wed, 15 Dec 2004 14:52:09 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CefKG-00081V-5t
	for simple@ietf.org; Wed, 15 Dec 2004 15:00:45 -0500
Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net
	[209.30.33.13]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBFJntuK070063
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Dec 2004 13:49:58 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <41C09563.3010403@nostrum.com>
Date: Wed, 15 Dec 2004 13:49:55 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Subject: Re: [Simple] Re: MSRP URLs
References: <414FFFCF.8020007@nokia.com>	<92748F4C-13F0-11D9-B01C-000D93B0AE1A@nostrum.com>
	<415E6FE2.7000602@nokia.com>
In-Reply-To: <415E6FE2.7000602@nokia.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: fluffy@cisco.com, SIMPLE mailing list <simple@ietf.org>, rohan@cisco.com
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit

Miguel Garcia wrote:

> Ben Campbell wrote:
>
>>>
>>> 4) According to rfc2396bis, "unrerved" is defined as:
>>>
>>> unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
>>>
>>> On purpose "unreserved" does not include "sub-delims", which is  
>>> defined as:
>>>
>>>     sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
>>>                   / "*" / "+" / "," / ";" / "="
>>>
>>> I guess it is OK for MSRP that the path is formed of unreserved  
>>> characters, not including sub-delims. But I would like to point 
>>> this  out in case someone feels the path needs to include sub-delims.
>>
>>
>>
>> If I recall correctly, we consciously chose to use unreserved on all 
>> of  this to avoid escaping. Does anyone see a requirement to use 
>> other  characters here than cannot be achieved with unreserved 
>> characters?
>
>
> I don't have such requirement. I just wanted to check that was a 
> decision taken on purpose, not an oversight.


The only thing I can think of that might make us want to reconsider this 
would be the fact that relays may choose to do some kind encoding of 
session state in the session identifier. One logical (and, for many 
environments, trivial) encoding of such identifiers would be using 
base64 -- which includes the "+", "/", and "=" characters. So, we may 
want to relax the restriction to '1*( unreserved / "+" / "=" / "/" )'. 
I'll note that we *do* want to make sure that ";" isn't valid in the 
session identifiers. On the other hand, implementors can simply take the 
suggestions from RFC3548 section 4 instead, in which case the only 
accommodation we would need to make is the equals sign.

/a

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


From simple-bounces@ietf.org  Wed Dec 15 16:59:09 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21471;
	Wed, 15 Dec 2004 16:59:09 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CehJC-0004uO-V6; Wed, 15 Dec 2004 17:07:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cegve-0002Xs-Ms; Wed, 15 Dec 2004 16:43:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cegi8-0001wt-HN; Wed, 15 Dec 2004 16:29:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16374;
	Wed, 15 Dec 2004 16:29:25 -0500 (EST)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CegqQ-0003Pd-Vo; Wed, 15 Dec 2004 16:38:03 -0500
Received: from lion.cs.columbia.edu
	(IDENT:0AdYcYE41m/MVBAr29sI1FZMIWehoDwR@lion.cs.columbia.edu
	[128.59.16.120])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBFLSNTO014917;
	Wed, 15 Dec 2004 16:28:23 -0500 (EST)
Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206])
	(authenticated bits=0)
	by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id iBFLSMRt013289
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Wed, 15 Dec 2004 16:28:22 -0500
Message-ID: <41C0AC71.3060001@cs.columbia.edu>
Date: Wed, 15 Dec 2004 16:28:17 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Simple] Usage of
	substitution	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>
	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>
	<41C02A85.3050608@nokia.com> <41C056C8.5070400@cisco.com>
In-Reply-To: <41C056C8.5070400@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0,
	Antispam-Data: 2004.12.15.27
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0,
	__SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>,
        Jari Urpalainen <jari.urpalainen@nokia.com>,
        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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Content-Transfer-Encoding: 7bit

As an additional datapoint:

http://www.w3.org/TR/xmlschema-0/

says (Section 5.5):

"The lax  value of the processContents  attribute instructs an XML 
processor to validate the element content on a can-do basis: It will 
validate elements and attributes for which it can obtain schema 
information, but it will not signal errors for those it cannot obtain 
any schema information."

That seems roughly what we want, with the exception of not being able to 
constrain the positioning of elements noted below.

Note that PIDF already provides a mechanism for mandatory-to-understand 
pieces of <status> extensions. As far as I can tell, it does not, 
however, indicate whether the composer or the watcher is obligated.

Paul Kyzivat wrote:
> 
> 
> Jari Urpalainen wrote:
> 
>> ext Paul Kyzivat wrote:
>>
>>> Jari,
>>>
>>> My concern is that I may sometime find myself to be an AOL subscriber 
>>> for presence. (Perhaps because that is the only place some of my 
>>> buddies are capable of accessing.)
>>>
>>> I don't want to be dependent on AOL to install support for a new 
>>> presence entity before I can begin to use it.
>>>
>>>     Paul
>>
>>
>>
>> If it so that the client only needs to "understand" this extension 
>> I'll agree but if you need also the server to "understand" it then I 
>> may disagree.
> 
> 
> Yes, the distinction is key.
> 
>> My point was and is that we'll have to select case-by-case the 
>> extension model. I am assuming that we all want unambiguous and 
>> consistent semantics. Looking from the schema validation pov we have 
>> at least these possibilities:
>> 1. using <any> with ##any or ##other namespace and with 
>> processContents "lax", "skip" or "strict".
>> 2. using abstract elements with substitionGroups
>> The latter is the most restrictive one (and of course you'll need the 
>> new definitions) although there's not a big difference in that respect 
>> with <any> with "strict".
> 
> 
> I think the problem is that we want the best of both, and that doesn't 
> seem to be possible. What I mean is:
> 
> - for those that don't understand it, we would like a treatment like 
> <any> with lax or skip. (I don't know xml well enough to understand the 
> difference between those.)
> 
> - for those that do understand the item, we would like it to be treated 
> with the substitution group semantics.
> 
> At least I think that is what we would like for PIDF extensions. In many 
> cases it is probably sufficient for the endpoints to understand the 
> extensions they want and ignore the rest. And for the presence server to 
> treat them generically without understanding them.
> 
> For sophisticated composition of presence documents a lack of 
> understanding of an element will perhaps lead to less than perfect 
> composition. But the decoupling of client evolution from server 
> evolution is sufficiently important that composition needs to be 
> designed to tolerate this.
> 
>> Speaking about the presence entity we'll get onto pidf, where the 
>> extension is based on <any>, "##other" and "lax" model. Let's say we 
>> are using rpid extension. So if the validator has rpid schema and the 
>> instance document uses e.g. <privacy> extension but instead of the 
>> requirement (<status>) puts that onto <tuple>. The validator can check 
>> that <privacy> is well formed and valid according to rpid schema but 
>> it doesn't know where it belongs within the pidf and will then 
>> validate the document. However, if substitutionGroup had been used it 
>> would have explicitly forbidden this.
> 
> 
> Yes, this was the motivation to use substitution groups. But if the 
> validator hasn't heard of <privacy> then validation fails even if it was 
> used correctly.
> 
> With <any>, it will pass on the server, but hopefully the receiving 
> client that does understand it will recognize that it is misplaced. But 
> that recognition of being misplaced then can't be part of the formal 
> validation logic, but must be hand coded.
> 
>  > So my point is that abstract types with
> 
>> substitutionGroups are very explicit and imo a good way to point the 
>> extension places in xml documents. Using <any> introduces vagueness to 
>> the validation process that I would prefer to avoid.
> 
> 
> The tradeoff is better validation in the server, but constraint that you 
> can't use a new feature until the server has been extended to support 
> it. For presence I think this is a bad tradeoff.
> 
>> So to summarize my preference is abstract elements with 
>> substitutionGroups in this context. However, if there's really a need 
>> e.g. for the case where the clients can use the extension before the 
>> server is being updated then there is not any other alternative than 
>> to use <any>.
> 
> 
> Sad. We need an extension mechanism different than what is available.
> 
>> So then back to the reality, are we looking in presence authorization 
>> e.g. something like ?
>>
>> <xs:element name="provide-extension" 
>> substitutionGroup="cr:transformation">
>>  ||<xs:complexType>
>>    <xs:any namespace="##other" processContents="lax" minOccurs="0" 
>> maxOccurs="unbounded">
>>  ||</xs:complexType>
>> </xs:element>
> 
> 
> Don't understand above.
> 
>     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  Thu Dec 16 05:20:05 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09659;
	Thu, 16 Dec 2004 05:20:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CessK-0004vx-8B; Thu, 16 Dec 2004 05:28:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CesiR-0001T3-FD; Thu, 16 Dec 2004 05:18:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CescE-0000Jj-9V
	for simple@megatron.ietf.org; Thu, 16 Dec 2004 05:12:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09277
	for <simple@ietf.org>; Thu, 16 Dec 2004 05:12:07 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ceskd-0004lv-A7
	for simple@ietf.org; Thu, 16 Dec 2004 05:20:51 -0500
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
	iBGA6On13503; Thu, 16 Dec 2004 12:06:29 +0200 (EET)
X-Scanned: Thu, 16 Dec 2004 12:05:16 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iBGA5GAC032157;
	Thu, 16 Dec 2004 12:05:16 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 007Nc23j; Thu, 16 Dec 2004 12:05:13 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBGA5CD21541; Thu, 16 Dec 2004 12:05:12 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh003.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 16 Dec 2004 12:05:10 +0200
Message-ID: <41C15DD7.10604@nokia.com>
Date: Thu, 16 Dec 2004 12:05:11 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <BDE5181D.1F9C5%fluffy@cisco.com>
In-Reply-To: <BDE5181D.1F9C5%fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Dec 2004 10:05:10.0898 (UTC)
	FILETIME=[BA81D520:01C4E356]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>, Rohan Mahy <rohan@ekabal.com>
Subject: [Simple] Re: MSRP: Report-Failure partial
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit

Cullen:

The explanation about partial looks good. I would welcome this kind of 
discussion written in the base draft, it will certainly help to 
understand things better.

- Miguel

Cullen Jennings wrote:

> The goal of "partial" was to report errors except timeouts. The timeout
> require the sending hop to run a timer and that receiving hop to send an
> acknowledgement to stop the timer. Some systems don't want the overhead of
> doing this so choose not to but still report other errors.
> 
> We may have the text messed up to describe this.
> 
> On 12/14/04 4:53 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:
> 
> 
>>Hi:
>>
>>I am trying to understand the concise procedures that affect the
>>Report-Failure: partial in MSRP, and I think I am missing something.
>>
>>On reading the MSRP draft I found contradictory text:
>>
>>- Second paragraph on 7.1.3 says:
>>
>>    If the endpoint receives a SEND request with a Report-Failure header
>>    field ...  "partial", it MUST NOT send a transaction response to the
>>    request, but SHOULD send an appropriate non-200 class response a
>>    failure occurs.
>>
>>So I understand that "partial" means "don't send 200, but send any other
>>response".
>>
>>- Section 7.3 says:
>>
>>    When the
>>    request is received, the To-Path will have exactly one URL, which
>>    MUST map to an existing session that is associated with the
>>    connection on which the request arrived.  If this is not true, and
>>    the request contained a Report-Failure header value of "no" or
>>    "partial", then the receiver SHOULD quietly ignore the request.  If
>>    the Report-Failure header is not present, or had a value of "yes",
>>    then the receiver MUST return a 481 response.
>>
>>Here the text says that "partial" means don't send a 481 response, which
>>is obviously in contradiction with 7.1.3.
>>
>>- Section 7.3.1 then says.
>>
>>    If the SEND request contained a Content-Type header field indicating
>>    an unsupported MIME type, the receiver SHOULD send a 415 response or
>>    failure report, as appropriate for the Report-Failure header field
>>    value.
>>
>>That is misleading me in another aspect: by reading the above text I may
>>think that the Report-Failure header field value determines whether and
>>endpoint sends failure responses or REPORT requests. So one could think
>>that "Report-Failure: yes" means send REPORt requests rather than
>>failure responses, whereas "Report-Failure: no" means the opposite. I
>>believe this is not the intention, right?
>>
>>So is this something that can be further clarified in the document?
>>
>>Regards,
>>
>>
>>         Miguel
>>
>>
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Thu Dec 16 05:23:30 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09772;
	Thu, 16 Dec 2004 05:23:30 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cesvd-0004zS-SL; Thu, 16 Dec 2004 05:32:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cesiw-0001cW-4r; Thu, 16 Dec 2004 05:19:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cesep-0000wY-Mm
	for simple@megatron.ietf.org; Thu, 16 Dec 2004 05:14:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09410
	for <simple@ietf.org>; Thu, 16 Dec 2004 05:14:49 -0500 (EST)
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CesnD-0004ok-P7
	for simple@ietf.org; Thu, 16 Dec 2004 05:23:33 -0500
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBGA8YD16288; Thu, 16 Dec 2004 12:08:37 +0200 (EET)
X-Scanned: Thu, 16 Dec 2004 12:07:39 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iBGA7dOG008503;
	Thu, 16 Dec 2004 12:07:39 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 004O4B3L; Thu, 16 Dec 2004 12:07:11 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBGA79D23037; Thu, 16 Dec 2004 12:07:09 +0200 (EET)
Received: from [172.21.35.181] ([172.21.35.181]) by esebh003.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 16 Dec 2004 12:07:06 +0200
Message-ID: <41C15E4B.8090605@nokia.com>
Date: Thu, 16 Dec 2004 12:07:07 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <BDE51AB9.1F9C9%fluffy@cisco.com>
In-Reply-To: <BDE51AB9.1F9C9%fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Dec 2004 10:07:06.0622 (UTC)
	FILETIME=[FF7BE9E0:01C4E356]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: Rohan Mahy <rohan@ekabal.com>, "simple@ietf.org" <simple@ietf.org>
Subject: [Simple] Re: MSRP: IANA considerations
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit

I think the registry is mostly needed. It is a matter of time whether 
you want to create the registry now or later. If the problem with doing 
it now is the time IANA requires to do an action, then shouldn't we 
start writing a I-D now that registers all this values? This way the 
IANA registration will not be a head-of-line blocking for MSRP and 
MSRP-relays.

- Miguel

Cullen Jennings wrote:

> Don't know what others think but I don't think a registry is needed for any
> of this. If later on there is great need for it, we could add it later (like
> we did for SIP). I don't care greatly but don't want to clog IAN que with
> stuff not critical.
> 
> 
> 
> On 12/13/04 6:14 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:
> 
> 
>>About MSRP and the IANA considerations: I noticed that MSRP does not
>>register any method, header, response code, etc. Then, MSRP relays says
>>in section 9 that there are no new requirements to IANA:
>>
>>Isn't this a bit mess without such registry? I would expect that MSRP
>>follows a similar policy than SIP. I would expect MSRP to open a new
>>MSRP registry with sub-registries for methods, headers, responses, etc.
>>
>>Let's take MSRP-Relays. However, at least I have detected quite a few
>>new "things" to be registered with IANA. Essentially, everything
>>described under Section 4, "Overview of New Protocol Elements"
>>
>>- New method: AUTH
>>
>>- New headers: Use-Path, Authorization, WWW-Authenticate,
>>Authentication-Info, Expires, Min-Expires, Max-Expires
>>
>>- New response code: 423 Out-of-bounds
>>
>>By the way: I am missing 401 Unauthorized from the above list in Section 4.
>>
>>Don't you think it would be easier to establish a registry with all
>>those sub-registries?
>>
>>Regards,
>>
>>           Miguel
>>
>>
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Thu Dec 16 15:49:28 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07682;
	Thu, 16 Dec 2004 15:49:27 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cf2hV-0007sQ-Gj; Thu, 16 Dec 2004 15:58:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cf2Sl-0004b1-C9; Thu, 16 Dec 2004 15:43:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf2NL-0001JT-Lm
	for simple@megatron.ietf.org; Thu, 16 Dec 2004 15:37:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06349
	for <simple@ietf.org>; Thu, 16 Dec 2004 15:37:25 -0500 (EST)
Received: from mgw-x2.nokia.com ([131.228.20.22])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf2Vp-0007SQ-Dd
	for simple@ietf.org; Thu, 16 Dec 2004 15:46:14 -0500
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBGKWQr13036; Thu, 16 Dec 2004 22:32:29 +0200 (EET)
X-Scanned: Thu, 16 Dec 2004 22:31:51 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iBGKVp9t018002;
	Thu, 16 Dec 2004 22:31:51 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00OvE8gN; Thu, 16 Dec 2004 22:30:59 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBGKUx300124; Thu, 16 Dec 2004 22:30:59 +0200 (EET)
Received: from [10.163.23.234] ([10.163.23.234]) by esebh003.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 16 Dec 2004 22:30:57 +0200
Message-ID: <41C1F082.3050405@nokia.com>
Date: Thu, 16 Dec 2004 22:30:58 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: cullen Jennings <fluffy@cisco.com>, rohan Mahy <rohan@ekabal.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Dec 2004 20:30:57.0798 (UTC)
	FILETIME=[26341A60:01C4E3AE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>
Subject: [Simple] MSRP-relays and HTTP Digest authentication
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit

Hi:

I think there is also something that deserves a bit more of discussion: 
the usage of HTTP Digest authentication in MSRP-relays.

An HTTP Digest response contains a checksum of the username, password, 
nonce, the method and the requested URI. Unlinke HTTP, MSRP does not 
offer the concept of the Request-URI. So is it the To-Path what we want 
to protect in the Digest checksum? The MSRP To-Path is the most similar 
thing to the HTTP Request-URI.

Note that the MSRP relays draft indicates in Section 8.1:

    Note that unlike
    in some usages of HTTP Authentication (for example, SIP), the uri
    parameter in the Authorize header is the same as the Request-URI in
    the request line of the MSRP parcel of the AUTH request.

which is the parragraph that requires further discussion.

- Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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


From simple-bounces@ietf.org  Fri Dec 17 03:36:40 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24223;
	Fri, 17 Dec 2004 03:36:40 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfDjz-0004cE-CJ; Fri, 17 Dec 2004 03:45:35 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfDa0-0005F4-L2; Fri, 17 Dec 2004 03:35:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfDXD-0004iV-Dk
	for simple@megatron.ietf.org; Fri, 17 Dec 2004 03:32:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23939
	for <simple@ietf.org>; Fri, 17 Dec 2004 03:32:22 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfDfo-0004UZ-7j
	for simple@ietf.org; Fri, 17 Dec 2004 03:41:17 -0500
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBH8WHn06077; Fri, 17 Dec 2004 10:32:18 +0200 (EET)
X-Scanned: Fri, 17 Dec 2004 10:37:34 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iBH8bY2B013858;
	Fri, 17 Dec 2004 10:37:34 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00BB6LMb; Fri, 17 Dec 2004 10:37:32 EET
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBH8Vw300886; Fri, 17 Dec 2004 10:31:58 +0200 (EET)
Received: from [172.21.34.238] ([172.21.34.238]) by esebh002.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 17 Dec 2004 10:31:58 +0200
Message-ID: <41C2997D.9010800@nokia.com>
Date: Fri, 17 Dec 2004 10:31:57 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for
	moving forward
References: <41B60EAD.5090504@cisco.com>
In-Reply-To: <41B60EAD.5090504@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Dec 2004 08:31:58.0607 (UTC)
	FILETIME=[DFA7B1F0:01C4E412]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82
Content-Transfer-Encoding: 7bit

Hi Jonathan,

First of all, thanks for pushing the resolution of this issue forward by
making a concrete proposal.

I don't think making the dispatcher visible to the composer/watcher 
actually solves the real problem; it does however reaffirm the statement 
made in the data model that unique contacts URIs are required in service 
tuples. The primary motivation for this requirement seems to be that it 
enables overriding service elements.

I think we are working with the wrong publication model to begin with, 
which makes override of service elements problematic. The publication 
model is that of a presentity employing a set of PUAs with equal rights 
-- no one PUA is more authoritative than another. They are all 
publishing their own full view of the presentity's service statuses.

This is much like a set of users running processes in an OS. Let's say 
that user 'apniemi' sees that a process run by 'calendar' has gone awry 
and is not responding. Using the current data model, fixing, or 
overriding this process would entail user 'apniemi' creating a new 
process, with matching properties (such as the pid), but a different 
binary, resulting in overriding the 'calendar' user's process. Normally, 
of course 'apniemi' probably wouldn't be able to do that, but instead, 
would need to become 'root' and 'kill' the process.

So I think ultimately, we need a new interface to the composer, call it 
root account, that gives us a way to "kill" publications that are 
publishing stale event state. Perhaps such an interface could be 
provided as part of the composer policy or authorization policy, but I 
don't think it necessarily requires uniqueness of service URIs.

If we reverse the assumption made in the data model that requires 
uniqueness of service URIs, will watchers generally be confused if they 
encounter service tuples with the same contact? I don't think so, as 
long as the watcher does the following:

1) takes note of the meta-information of each service (timestamp, 
q-value) giving preference to a fresher service, or one with higher q-value.

2) takes note of the characteristics of each service (prescaps for 
example) along with the contact URI, applying its own known 
characteristics and service URIs to determine what service the tuple is 
describing

3) takes note of the status, meaning that a basic status of OPEN is a 
better choice than one with CLOSED, for example

4) all of the above being equal, folds all identical services together 
(after all they are identical in all ways that have relevance to the 
watcher)

These steps should guarantee that the watcher can always make a proper 
selection of which service to invoke. Invoking the service then involves 
more than a simple "clicking the contact", since in the case of SIP the 
watcher generally will e.g. construct an SDP offer that matches the 
service that the watcher thinks the tuple is describing. I believe the 
invoking of a service MUST work using an AoR. If an INVITE offering 
voice ends up served by a chess application, I think the system is 
utterly broken, and needs to be fixed. One fix could be using GRUUs as 
contacts, but that is not the only fix, and may not even be the best 
one, IMHO.

All and all, I still don't buy the requirement for unique service URIs. 
Also, I think that the default composer policy of union (i.e., collect 
all service tuples together intact) will take care of the 95% need, 
leaving out more sophisticated things like override and 
merging/splitting for future study. These more sophisticated needs can 
be tackled later, when more real-world experience has been accumulated 
about them. I don't think we currently are able to see exactly what the 
needs of this 5% are, so the best way forward is to take the 95%, make 
it as flexible as possible to accommodate this future work and run with it.

Cheers,
Aki

ext Jonathan Rosenberg wrote:
> We've gotten ourselves stuck lately in a few places in the presence data 
> model. In particular, folks have come forward with requirements for 
> having multiple services with the same URI. The use cases that have been 
> brought forward include:
> 
> 1. I have a softphone on my PC that is one integrated application, 
> available at one AOR with one contact/gruu. I'd like to be able to say 
> that I'm available for IM but not available for voice.
> 
> 2. I have a cell phone that has a common SIP stack by which other 
> applications can "register". The sip stack dispatches incoming SIP 
> requests to different applications depending on characteristics of the 
> request. For example, based on method, codec, media types, SIP 
> extensions, URI parameters, etc.
> 
> 
> The data model does not, as currently defined, readily handle these 
> cases. In my view, the issue of "can we have the same URI for two 
> services or not" is a detail around a more general modeling question 
> that we have not addressed properly. I think that more general modeling 
> question is how we think about dispatchers. Dispatchers are software 
> agents which receive service reuqests, but don't directly process them. 
> Rather, they dispatch them to another service for processing. By this 
> definition, a SIP proxy is a dispatcher. The SIP stack in example 2 
> above is also a dispatcher. You could *model* the integrated application 
> in example 1 as a dispatcher fronting different services that all happen 
> to run in the same process.
> 
> A dispatcher is associated with a URI, just like a service as currently 
> defined in the model. However, in the model today, there is no way to 
> explicitly tell the watcher - "hey, if you invoke this URI, you'll get 
> dispatched to 1 of these services depending on some policy". All we can 
> do today is have the compositor attempt to compose the component 
> services being dispatched to, and thus hide the existence of the 
> underlying component services. Where we appear to be running into 
> trouble is when we want to expose these component services to the 
> watcher, but still convey the fact that there is a dispatcher there - 
> usually by trying to publish them all with the same URI.
> 
> Since the goal of the data model is to be extremely explicit about what 
> presence is, I think the approach we should take here is to be very 
> explicit about how we represent dispatchers. As such, I would propose 
> the following:
> 
> 1. Dispatchers be added to the model as a type of service. Like other 
> services, they have a <contact> which is the URI you would use to access 
> the dispatcher service. They can have characteristics and status. The 
> most important characteristic of the dispatcher service is the set of 
> services to which the dispatcher will dispatch. This would be enumerated 
> explicitly as part of the characteristics of the dispatcher. These 
> component services could be specified by URI or by some other identifier 
> that serves only to link the component service to the dispatcher.
> 
> 2. Since dispatchers are services, they can publish their status too. 
> This means that, for example, a proxy could PUBLISH (at least 
> conceptually) a tuple to a compositor that defines the dispatch 
> operation it provides when it receives a request for a particular AOR. 
> The current data model is kind of vague about how a compositor would 
> know to combine certain services together. The answer is provided by 
> this dispatcher. The dispatcher tuple explicitly tells the compositor 
> what the "input" URI is, and what the "output" URIs would be.
> 
> I'll note tha the reg-event package provides similar information, but 
> dispatching is more general than registration.
> 
> 3. If you have a "dumb" compositor which simply unions together the 
> information it gets, when that information contains the component 
> services in addition to the dispatcher service, it allows the watcher to 
> compose together the component services.
> 
> 4. A service in the model is most usefully thought of as a "software 
> agent". It is a software process running somewhere on the network. Its 
> <contact> URI necessarily indicates the address to which a request has 
> to be sent in order to be received by that software agent. When an agent 
> publishes its own status, it knows its own URI since that is the address 
> it is listening at for requests. There needs to be truth in advertising 
> for this to work; a software agent representing a service should never 
> publish a <contact> that its not actually receiving requests for.
> 
> 
> 
> Here are a few examples to make this more concrete.
> 
> Example 1: Proxy
> 
> Two SIP UAs, on two different PCs, each registering under the same AOR. 
> Each UA is a software agent, and provides a service. Each one 
> self-publishes (that is, the software agent providing the service is the 
> same one generating the PUBLISH request). The pidf document published by 
> one of the UA might look something like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:1.2.3.4</contact>
>      </tuple>
>    </presence>
> 
> Lets say the other UA publishes a similar document, but with a contact 
> of 5.6.7.8 and a status of closed.
> 
> Lets say the compositor knows about the registrations of those UA. The 
> proxy that does the location processing can be modeled as a dispatcher 
> service. As a result, the compositor can construct the following 
> document which models the proxy:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s9">
>        <dispatch-to>
>           <uri>sip:1.2.3.4</uri>
>           <uri>sip:5.6.7.8</uri>
>        </dispatch-to>
>        <contact>sip:jdrosen@example.com</contact>
>      </tuple>
>    </presence>
> 
> 
> This says that there is a service at jdrosen@example.com which is a 
> dispatcher, dispatching to the two contacts. Using the three documents 
> it now has, the compositor can produce several results. One is the 
> "transparent" document, which merely combines all of the data:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s9">
>        <dispatch-to>
>           <uri>sip:1.2.3.4</uri>
>           <uri>sip:5.6.7.8</uri>
>        </dispatch-to>
>        <contact>sip:jdrosen@example.com</contact>
>      </tuple>
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:1.2.3.4</contact>
>      </tuple>
>      <tuple id="ub93s4">
>        <status>
>          <basic>closed</basic>
>        </status>
>        <contact>sip:5.6.7.8</contact>
>      </tuple>
>    </presence>
> 
> 
> This is a basic "union" operation. Note that the document provides 
> sufficient context for a watcher to know how to combine the two 
> component services; it knows that they are both reachable through a 
> dispatcher. Indeed, in this case, they may ONLY be reachable through the 
> dispatcher since the <contact> URIs of the two component services may 
> not be directly routable.
> 
> Or, instead of being transparent, the compositor can combine the three 
> tuples and advertise a single tuple. This single tuple routes to the 
> dispatcher, but doesn't make it explicit to the watcher that there is a 
> dispatcher; the component services are hidden and the dispatcher is made 
> to look like a regular service:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <presence xmlns="urn:ietf:params:xml:ns:pidf"
>        xmlns:local="urn:example-com:pidf-status-type"
>        entity="sip:jdrosen@cisco.com">
>      <tuple id="ub93s3">
>        <status>
>          <basic>open</basic>
>        </status>
>        <contact>sip:jdrosen@cisco.com</contact>
>      </tuple>
>    </presence>
> 
> What does this mean in terms of the URIs that get put within the 
> <contact> elements of each tuple? I think the following can be said:
> 
>   a. since each tuple represents a unique service, and since a service 
> is associated with a software agent that provides it, there has to, by 
> definition, be a unique URI per service.
> 
>   b. If two tuples in a document have the same service URI, it means 
> that there have been conflicting tuples generated for the same service.
> 
>   c. some services may only be reachable through the dispatcher, in 
> which case their URIs may not be particularly relevant. They would only 
> serve the purposes of correlating the component service to its 
> dispatcher. Thus, a gruu would not be needed per se - a contact URI 
> would suffice.
> 
>   d. If an agent is self-publishing (that is, publishing a tuple about 
> itself), the <contact> URI should route to it as far as it knows 
> definitively. This would mean that the contact URI of its registration 
> or the gruu would do, but not the AOR.
> 
>   e. If an agent is third-party publishing, things are more flexible. If 
> a UA knows that there are no other UA registered against a particular 
> AOR, and if it knows that the proxy itself is not publishing its 
> dispatch service, the UA can perform the composition of the two agents 
> in the picture (the proxy and the UA), and publish a tuple representing 
> the service provided by the *proxy*. In this case, the tuple could have 
> the AOR as the <contact>. However, this can be brittle, since the 
> ability of the UA to do this is based on it knowing a lot about what 
> else is being published. The safest bet is self-publication, since it is 
> the approach with the highest likelihood of correctness.
> 
> Comments welcome,
> Jonathan R.


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


From simple-bounces@ietf.org  Fri Dec 17 05:43:19 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03792;
	Fri, 17 Dec 2004 05:43:19 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfFia-0008A6-7e; Fri, 17 Dec 2004 05:52:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfFXC-0004dl-TP; Fri, 17 Dec 2004 05:40:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfFSl-0003I6-92; Fri, 17 Dec 2004 05:35:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03224;
	Fri, 17 Dec 2004 05:35:53 -0500 (EST)
Received: from mgw-x2.nokia.com ([131.228.20.22])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfFbN-0007xQ-F3; Fri, 17 Dec 2004 05:44:49 -0500
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBHAZgr19793; Fri, 17 Dec 2004 12:35:43 +0200 (EET)
X-Scanned: Fri, 17 Dec 2004 12:35:05 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iBHAZ5Dn011059;
	Fri, 17 Dec 2004 12:35:05 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks003.ntc.nokia.com 00uDz5i6; Fri, 17 Dec 2004 12:35:05 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBHAZ5302511; Fri, 17 Dec 2004 12:35:05 +0200 (EET)
Received: from kusti.research.nokia.com ([172.21.56.13]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 17 Dec 2004 12:33:46 +0200
Received: from [172.21.50.105] (xitami.research.nokia.com [172.21.50.105])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id D165F93B78; Fri, 17 Dec 2004 12:33:44 +0200 (EET)
Message-ID: <41C2B529.40807@nokia.com>
Date: Fri, 17 Dec 2004 12:30:01 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Simple] Usage of
	substitution	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>
	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>
	<41C02A85.3050608@nokia.com> <41C056C8.5070400@cisco.com>
	<41C0AC71.3060001@cs.columbia.edu>
In-Reply-To: <41C0AC71.3060001@cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Dec 2004 10:33:46.0526 (UTC)
	FILETIME=[E383A3E0:01C4E423]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
        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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit

ext Henning Schulzrinne wrote:

> As an additional datapoint:
>
> http://www.w3.org/TR/xmlschema-0/
>
> says (Section 5.5):
>
> "The lax  value of the processContents  attribute instructs an XML 
> processor to validate the element content on a can-do basis: It will 
> validate elements and attributes for which it can obtain schema 
> information, but it will not signal errors for those it cannot obtain 
> any schema information."
>
> That seems roughly what we want, with the exception of not being able 
> to constrain the positioning of elements noted below.
>
If there's only a single extension point then also this positioning 
problem vanishes. However, I still have a problem understanding 
(regarding common-policy) "what we want" as I can't see any problem with 
the current draft besides perhaps the usefulness of Content-Type 
registration which is imo needed in presence-rules instead.

> Note that PIDF already provides a mechanism for 
> mandatory-to-understand pieces of <status> extensions. As far as I can 
> tell, it does not, however, indicate whether the composer or the 
> watcher is obligated.
>
This mechanism is also beyond what schema validation can do.

> Paul Kyzivat wrote:
>
>>
>>
>>
>>> So then back to the reality, are we looking in presence 
>>> authorization e.g. something like ?
>>>
>>> <xs:element name="provide-extension" 
>>> substitutionGroup="cr:transformation">
>>>  ||<xs:complexType>
>>>    <xs:any namespace="##other" processContents="lax" minOccurs="0" 
>>> maxOccurs="unbounded">
>>>  ||</xs:complexType>
>>> </xs:element>
>>
>>
>>
>> Don't understand above.
>>
>>     Paul
>
This was my attempt to ask where are the missing extension points in 
presence rules. After I re-glanced the draft I found 
<provide-unknown-attribute> which approximately does the same thing that 
I had in mind. However, looking at these <transformations> they all (at 
least most of them) are such that they can easily be implemented with 
XPath semantics which is also the model in the current filtering drafts. 
I am inclined to prefer that model because of it's  flexibility and 
inherent extensibility.

br,
Jari


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


From simple-bounces@ietf.org  Fri Dec 17 13:27:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17841;
	Fri, 17 Dec 2004 13:27:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfMyA-0006dt-4Y; Fri, 17 Dec 2004 13:36:50 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfMin-0002tM-Bg; Fri, 17 Dec 2004 13:20:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcGhx-0003RS-3x
	for simple@megatron.ietf.org; Thu, 09 Dec 2004 00:19:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04648
	for <simple@ietf.org>; Thu, 9 Dec 2004 00:19:14 -0500 (EST)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGoq-0004M8-Pp
	for simple@ietf.org; Thu, 09 Dec 2004 00:26:26 -0500
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by
	parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 9 Dec 2004 06:19:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Dec 2004 06:19:01 +0100
Message-ID: <B30D6148F304A743A53B9B44751CDB9A025577F8@FTRDMEL2.rd.francetelecom.fr>
Thread-Topic: Question concerning draft-ietf-simple-presence-rules-01
Thread-Index: AcTdrpjt923W95OdS3uVadKjU5LB6A==
From: "MARJOU Xavier RD-MAPS-LAN" <xavier.marjou@francetelecom.com>
To: <jdrosen@cisco.com>
X-OriginalArrivalTime: 09 Dec 2004 05:19:11.0712 (UTC)
	FILETIME=[9DF19600:01C4DDAE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 17 Dec 2004 13:20:56 -0500
Cc: simple@ietf.org
Subject: [Simple] Question concerning draft-ietf-simple-presence-rules-01
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: quoted-printable

Hi,

I have a use-case were I want to make some transformations for a given
identity (eg: good buddy) and others transformations for all other
possible identities (eg: rest of the world).
>From draft-ietf-geopriv-common-policy-03, I understand that it is not
possible to implement it? Am I correct?

Thanks,
Xavier


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


From simple-bounces@ietf.org  Fri Dec 17 13:30:16 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18036;
	Fri, 17 Dec 2004 13:30:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfN0X-0006iP-IL; Fri, 17 Dec 2004 13:39:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfMin-0002tR-TD; Fri, 17 Dec 2004 13:20:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cd6Oj-0008Lm-4w; Sat, 11 Dec 2004 07:30:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18592;
	Sat, 11 Dec 2004 07:30:51 -0500 (EST)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cd6W6-0001SZ-N4; Sat, 11 Dec 2004 07:38:32 -0500
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60428
	helo=[192.168.0.5])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1Cd6OC-0000bm-Kj; Sat, 11 Dec 2004 12:30:20 +0000
In-Reply-To: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>
	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
Date: Sat, 11 Dec 2004 12:30:12 +0000
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 17 Dec 2004 13:20:56 -0500
Cc: Simple WG <simple@ietf.org>, mmusic@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit

On 10 Dec 2004, at 21:41, Ben Campbell wrote:
> I really need to get closure on this, so I'd appreciate people 
> agreeing or disagreeing.
>
> I have had off-list correspondence indicating both positions. In 
> summary:
>
> In favor of the change, I had a comment to the effect that changing 
> SDP semantics to ignore the C line and the port field on the M line 
> really changes it to something that is no longer SDP, and that such 
> deviations are in general bad for interop.
>
> In favor of leaving things as currently specified, I had two comments 
> that decomposing URLs into the C and M lines is ugly, and that having 
> a different mechanism to communicate endpoint addresses vs relay 
> addresses is really ugly.
>
> So, do people agree with one or the other position?

Decomposing the URL into the "c=" and "m=" lines is very ugly. 
Unfortunately, that ugliness is required if you want to use SDP. This 
is why the SDPng work was started, to try to move to something less 
horrible...

Colin


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


From simple-bounces@ietf.org  Fri Dec 17 13:33:29 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18307;
	Fri, 17 Dec 2004 13:33:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfN3f-0006ov-3T; Fri, 17 Dec 2004 13:42:31 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfMio-0002tW-Gy; Fri, 17 Dec 2004 13:20:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdSN9-0007ah-DE; Sun, 12 Dec 2004 06:58:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21345;
	Sun, 12 Dec 2004 06:58:40 -0500 (EST)
Received: from imh.informatik.uni-bremen.de ([134.102.224.4]
	helo=informatik.uni-bremen.de)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdSUj-0005M2-SM; Sun, 12 Dec 2004 07:06:34 -0500
Received: from tzi.uni-bremen.de (imh [134.102.224.4])
	by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id
	iBCBwNcP017372; Sun, 12 Dec 2004 12:58:31 +0100 (MET)
Message-ID: <41BC325D.4010808@tzi.uni-bremen.de>
Date: Sun, 12 Dec 2004 12:58:21 +0100
From: Joerg Ott <jo@tzi.uni-bremen.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
	<6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
In-Reply-To: <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 17 Dec 2004 13:20:56 -0500
Cc: Simple WG <simple@ietf.org>, mmusic@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit

I agree with Colin on the ugliness issue of decomposing URLs into
c= and m= lines.  But this is the way SDP has worked and works today.

The present discussion we are having here is about changing SDP to
for address/URL handling in one particular case.  This does not
strike me as something MSRP should be concerned with.

I would like to make one thing clear: we are either using existing tools
in another document or we are building new ones.  There is nothing much
in between.

Changing c=/m= semantics means changing SDP.  Just because the syntax
still looks the same does not mean that it is still the same protocol.
Any entity or generic protocol engine used to dealing with SDP m=/c=
would no longer do the right thing.

We see this kind of approach quite often -- by far too often -- over
the past years (just think the many "uses" of SIP defined elsewhere,
usually resulting in something "a little but not entirely unlike" SIP).

What I would like avoid is having special treatment of SDP depending
on what the media type is (or other attributes signify).

Therefore, I strongly agree with Colin's conclusion: take SDP as is
or leave it altogether and pursue a different path.

Joerg


Colin Perkins wrote:

> On 10 Dec 2004, at 21:41, Ben Campbell wrote:
> 
>> I really need to get closure on this, so I'd appreciate people 
>> agreeing or disagreeing.
>>
>> I have had off-list correspondence indicating both positions. In summary:
>>
>> In favor of the change, I had a comment to the effect that changing 
>> SDP semantics to ignore the C line and the port field on the M line 
>> really changes it to something that is no longer SDP, and that such 
>> deviations are in general bad for interop.
>>
>> In favor of leaving things as currently specified, I had two comments 
>> that decomposing URLs into the C and M lines is ugly, and that having 
>> a different mechanism to communicate endpoint addresses vs relay 
>> addresses is really ugly.
>>
>> So, do people agree with one or the other position?
> 
> 
> Decomposing the URL into the "c=" and "m=" lines is very ugly. 
> Unfortunately, that ugliness is required if you want to use SDP. This is 
> why the SDPng work was started, to try to move to something less 
> horrible...
> 
> Colin
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 



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


From simple-bounces@ietf.org  Fri Dec 17 17:41:06 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22350;
	Fri, 17 Dec 2004 17:41:06 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfQvJ-0001Qa-KB; Fri, 17 Dec 2004 17:50:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfQTV-00082h-PK; Fri, 17 Dec 2004 17:21:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfQHD-0002fz-Uk
	for simple@megatron.ietf.org; Fri, 17 Dec 2004 17:08:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17721
	for <simple@ietf.org>; Fri, 17 Dec 2004 17:08:41 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQPt-00089R-8Y
	for simple@ietf.org; Fri, 17 Dec 2004 17:17:44 -0500
Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHM3VuM003740
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 17 Dec 2004 16:03:33 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <41BD853E.7070400@ericsson.com>
References: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>
	<41BD853E.7070400@ericsson.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7EB139FB-5077-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] MSRP: sdp usage compared to BFCP
Date: Fri, 17 Dec 2004 16:03:34 -0600
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        Simple WG <simple@ietf.org>, Robert Sparks <RjS@xten.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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit


On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:

>
>> 1) BFCP depends on COMEDIA. MSRP does not.
>> The reason MSRP does not invoke COMEDIA is mainly a historic one. At 
>> the time we wrote that part of the spec, COMEDIA had not progressed 
>> as far as it has now. Instead, MSRP states a default connection 
>> "direction", and says that other mechanisms can be used to determine 
>> direction once they become standardized.
>
> The thing is that, most likely, comedia will be ready before both BFCP 
> and MSRP. So, arguing that comedia will not be ready is not a valid 
> argument anymore.
>
> Comedia defines two SDP attributes (setup and connection) that are 
> used to figure out which end initiates the TCP connection and, on 
> reception of a new offer, whether the TCP connection needs to be 
> re-established or the existing TCP connection is OK.
>
> I do not think that using these attributes would add too much 
> complexity to the protocol and having a way to know whether or not an 
> offer implies that the TCP connection needs to be re-established but 
> the rest of the parameters should not change seems like important 
> funcionality. So, even if you want to avoid using the setup attribute 
> (for some reason) by defining a default connection initiator, I 
> believe you may still want to use the connection attribute.
>

Technically, I agree that using comedia is a good idea. My concern now 
is simply that every new thing we add is that much more delay in 
completing MSRP. I don't think think it is trivial to add it, as the 
presence of relays complicates things.  I see two possible ways to move 
forward with this:

1) Leave MSRP as is, and follow up shortly with a draft on how to use 
COMEDIA with MSRP. I think this could be done in a backwards compatible 
way, by saying that if the COMEDIA attributes are not present, it falls 
back to the default behavior.

2) Go ahead and add COMEDIA support to the base spec, with a small but 
non-trivial delay while we make sure we don't break something.

Thoughts? (encouraged from anyone, but _particularly_ from the 
chairs...)

Ben.


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


From simple-bounces@ietf.org  Fri Dec 17 17:43:14 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22720;
	Fri, 17 Dec 2004 17:43:14 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfQxM-0001YF-Fm; Fri, 17 Dec 2004 17:52:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfQVp-0000fn-DN; Fri, 17 Dec 2004 17:23:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfQQE-0006VO-Cu; Fri, 17 Dec 2004 17:18:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19192;
	Fri, 17 Dec 2004 17:17:59 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfQYw-0000J3-3n; Fri, 17 Dec 2004 17:27:02 -0500
Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHMHtkO004838
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 17 Dec 2004 16:17:56 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <41BC325D.4010808@tzi.uni-bremen.de>
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
	<6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
	<41BC325D.4010808@tzi.uni-bremen.de>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <81AAFAB1-5079-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
Date: Fri, 17 Dec 2004 16:17:58 -0600
To: Joerg Ott <jo@tzi.uni-bremen.de>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org, Colin Perkins <csp@csperkins.org>,
        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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit


On Dec 12, 2004, at 5:58 AM, Joerg Ott wrote:

> I agree with Colin on the ugliness issue of decomposing URLs into
> c= and m= lines.  But this is the way SDP has worked and works today.
>
> The present discussion we are having here is about changing SDP to
> for address/URL handling in one particular case.  This does not
> strike me as something MSRP should be concerned with.
>
> I would like to make one thing clear: we are either using existing 
> tools
> in another document or we are building new ones.  There is nothing much
> in between.
>
> Changing c=/m= semantics means changing SDP.  Just because the syntax
> still looks the same does not mean that it is still the same protocol.
> Any entity or generic protocol engine used to dealing with SDP m=/c=
> would no longer do the right thing.
>
> We see this kind of approach quite often -- by far too often -- over
> the past years (just think the many "uses" of SIP defined elsewhere,
> usually resulting in something "a little but not entirely unlike" SIP).
>
> What I would like avoid is having special treatment of SDP depending
> on what the media type is (or other attributes signify).
>
> Therefore, I strongly agree with Colin's conclusion: take SDP as is
> or leave it altogether and pursue a different path.
>

I am sensitive to the philosophical desire to keep things pure, but on 
the pragmatic side this seems to me to be a false dichotomy. We extend 
protocols all the time, for good or ill. Can you describe specific 
interoperability problems that would be introduced by the MSRP usage as 
currently described?

How about this as a potential compromise:

We keep the path attribute as is, but _also_ copy the information for 
the endpoint into the m and c lines. This would seem to me to be 
consistent with the usage in the current ICE draft, in which ICE aware 
endpoints use the candidate attributes to determine the address and 
port, but the default address and port are copied into the m and c line 
for backwards compatibility? Considering that the ICE need for 
backwards compatibility seems much more clear than the MSRP need for 
the same?


> Joerg
>
>
> Colin Perkins wrote:
>
>> On 10 Dec 2004, at 21:41, Ben Campbell wrote:
>>> I really need to get closure on this, so I'd appreciate people 
>>> agreeing or disagreeing.
>>>
>>> I have had off-list correspondence indicating both positions. In 
>>> summary:
>>>
>>> In favor of the change, I had a comment to the effect that changing 
>>> SDP semantics to ignore the C line and the port field on the M line 
>>> really changes it to something that is no longer SDP, and that such 
>>> deviations are in general bad for interop.
>>>
>>> In favor of leaving things as currently specified, I had two 
>>> comments that decomposing URLs into the C and M lines is ugly, and 
>>> that having a different mechanism to communicate endpoint addresses 
>>> vs relay addresses is really ugly.
>>>
>>> So, do people agree with one or the other position?
>> Decomposing the URL into the "c=" and "m=" lines is very ugly. 
>> Unfortunately, that ugliness is required if you want to use SDP. This 
>> is why the SDPng work was started, to try to move to something less 
>> horrible...
>> Colin
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mmusic
>


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


From simple-bounces@ietf.org  Fri Dec 17 17:45:01 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22882;
	Fri, 17 Dec 2004 17:45:01 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfQyi-0001aY-Oy; Fri, 17 Dec 2004 17:54:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfQW4-0000ld-Gz; Fri, 17 Dec 2004 17:24:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfQRi-00076V-S3; Fri, 17 Dec 2004 17:19:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19366;
	Fri, 17 Dec 2004 17:19:32 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfQaR-0000Mk-20; Fri, 17 Dec 2004 17:28:35 -0500
Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHMJTRd005000
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 17 Dec 2004 16:19:30 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <C7C9823E-4CE6-11D9-8A90-000D93C60BA0@telio.no>
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>
	<6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>
	<41BC325D.4010808@tzi.uni-bremen.de>
	<C7C9823E-4CE6-11D9-8A90-000D93C60BA0@telio.no>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B9A3E5F5-5079-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
Date: Fri, 17 Dec 2004 16:19:31 -0600
To: Hisham Khartabil <hisham.khartabil@telio.no>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org, Joerg Ott <jo@tzi.uni-bremen.de>,
        Colin Perkins <csp@csperkins.org>, 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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Content-Transfer-Encoding: 7bit


On Dec 13, 2004, at 3:10 AM, Hisham Khartabil wrote:

> (not as chair, but as an MSRP protocol contributor)
>
> The objection to using the SDP c and m lines is not purely a cosmetic 
> objection. We are not saying that SDP the way it is defined today is 
> ugly so we want to rearrange it to look better.
>
> We have a fundamental objection: having 2 ways to construct a next hop 
> URI that depends on the entity that is the next hop is not acceptable. 
> Endpoints should not be required  to have 2 engines implemented. 
> Unless we are given an alternative that allows endpoint implementers 
> to implement one piece of code for constructing an next hop MSRP URI, 
> I'm afraid we have no choice but to keep what we have today in MSRP as 
> is.
>

I think Hisham expressed my concern much more precisely than I 
previously expressed it. This is exactly what I was trying to say.


> You telling us to go find another protocol if we don't like SDP the 
> way it is today is hardly contructive. SDPng is not an option and we 
> call know it.
>
> Let me add that comedia also violates what you claim to be a 
> fundamental piece of the protocol that if broken will cause the SDP 
> protocol not to be SDP any longer. An argument that I don't buy. We 
> have violated things before:
>
>    - t= line does not mean anything in SIP and is set to 0 0 (which in 
> SDP means that the session is permanent and unbounded).
>    - s= line carries session name. It is set to - when used with SIP.
>
> Also, quoting the SDP draft:
>
> "For unicast IP sessions, the following are conveyed:
>
>    o  The remote address for media
>
>    o  The remote transport port for media
>
>    The semantics of this address and port depend on the media and
>    transport protocol defined.  By default, this SHOULD be the remote
>    address and remote port to which data is sent.  Some media types MAY
>    redefine this behaviour, but this is NOT RECOMMENDED."
>
> We are changing the semantics. As far as I understand from the quoted 
> paragraph above, we are not violating anything, even-though it is not 
> recommended.
>
> I have a question to SDP stack implementers that plan to implement 
> MSRP: Does the current way MSRP specifies the use of SDP (ignore the c 
> line address and the m line port and instead use the attribute a=path) 
> cause problems to you and requires you to do some hacking in your SDP 
> stack? If so, is that acceptable or do you prefer for your MSRP 
> implementation to implement two ways of contructing an MSRP URL 
> depending on the what the next hop is?
>
> Regards,
> Hisham
>
> On Dec 12, 2004, at 12:58 PM, Joerg Ott wrote:
>
>> I agree with Colin on the ugliness issue of decomposing URLs into
>> c= and m= lines.  But this is the way SDP has worked and works today.
>>
>> The present discussion we are having here is about changing SDP to
>> for address/URL handling in one particular case.  This does not
>> strike me as something MSRP should be concerned with.
>>
>> I would like to make one thing clear: we are either using existing 
>> tools
>> in another document or we are building new ones.  There is nothing 
>> much
>> in between.
>>
>> Changing c=/m= semantics means changing SDP.  Just because the syntax
>> still looks the same does not mean that it is still the same protocol.
>> Any entity or generic protocol engine used to dealing with SDP m=/c=
>> would no longer do the right thing.
>>
>> We see this kind of approach quite often -- by far too often -- over
>> the past years (just think the many "uses" of SIP defined elsewhere,
>> usually resulting in something "a little but not entirely unlike" 
>> SIP).
>>
>> What I would like avoid is having special treatment of SDP depending
>> on what the media type is (or other attributes signify).
>>
>> Therefore, I strongly agree with Colin's conclusion: take SDP as is
>> or leave it altogether and pursue a different path.
>>
>> Joerg
>>
>>
>> Colin Perkins wrote:
>>
>>> On 10 Dec 2004, at 21:41, Ben Campbell wrote:
>>>> I really need to get closure on this, so I'd appreciate people 
>>>> agreeing or disagreeing.
>>>>
>>>> I have had off-list correspondence indicating both positions. In 
>>>> summary:
>>>>
>>>> In favor of the change, I had a comment to the effect that changing 
>>>> SDP semantics to ignore the C line and the port field on the M line 
>>>> really changes it to something that is no longer SDP, and that such 
>>>> deviations are in general bad for interop.
>>>>
>>>> In favor of leaving things as currently specified, I had two 
>>>> comments that decomposing URLs into the C and M lines is ugly, and 
>>>> that having a different mechanism to communicate endpoint addresses 
>>>> vs relay addresses is really ugly.
>>>>
>>>> So, do people agree with one or the other position?
>>> Decomposing the URL into the "c=" and "m=" lines is very ugly. 
>>> Unfortunately, that ugliness is required if you want to use SDP. 
>>> This is why the SDPng work was started, to try to move to something 
>>> less horrible...
>>> Colin
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mmusic
>>
>
>
> _______________________________________________
> 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 Dec 17 18:02:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26636;
	Fri, 17 Dec 2004 18:02:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfRGH-000310-82; Fri, 17 Dec 2004 18:11:50 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfQrq-0003y7-Rc; Fri, 17 Dec 2004 17:46:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfQiW-0004WO-Km
	for simple@megatron.ietf.org; Fri, 17 Dec 2004 17:36:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21761
	for <simple@ietf.org>; Fri, 17 Dec 2004 17:36:54 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQrF-0001EA-AU
	for simple@ietf.org; Fri, 17 Dec 2004 17:45:57 -0500
Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHMaqlO006443
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 17 Dec 2004 16:36:53 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <41C09563.3010403@nostrum.com>
References: <414FFFCF.8020007@nokia.com>	<92748F4C-13F0-11D9-B01C-000D93B0AE1A@nostrum.com>
	<415E6FE2.7000602@nokia.com> <41C09563.3010403@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <27A86F63-507C-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] Re: MSRP URLs
Date: Fri, 17 Dec 2004 16:36:55 -0600
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: fluffy@cisco.com, Miguel Garcia <Miguel.An.Garcia@nokia.com>,
        SIMPLE mailing list <simple@ietf.org>, rohan@cisco.com
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit


On Dec 15, 2004, at 1:49 PM, Adam Roach wrote:

> Miguel Garcia wrote:
>
>> Ben Campbell wrote:
>>
>>>>
>>>> 4) According to rfc2396bis, "unrerved" is defined as:
>>>>
>>>> unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
>>>>
>>>> On purpose "unreserved" does not include "sub-delims", which is  
>>>> defined as:
>>>>
>>>>     sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
>>>>                   / "*" / "+" / "," / ";" / "="
>>>>
>>>> I guess it is OK for MSRP that the path is formed of unreserved  
>>>> characters, not including sub-delims. But I would like to point 
>>>> this  out in case someone feels the path needs to include 
>>>> sub-delims.
>>>
>>>
>>>
>>> If I recall correctly, we consciously chose to use unreserved on all 
>>> of  this to avoid escaping. Does anyone see a requirement to use 
>>> other  characters here than cannot be achieved with unreserved 
>>> characters?
>>
>>
>> I don't have such requirement. I just wanted to check that was a 
>> decision taken on purpose, not an oversight.
>
>
> The only thing I can think of that might make us want to reconsider 
> this would be the fact that relays may choose to do some kind encoding 
> of session state in the session identifier. One logical (and, for many 
> environments, trivial) encoding of such identifiers would be using 
> base64 -- which includes the "+", "/", and "=" characters. So, we may 
> want to relax the restriction to '1*( unreserved / "+" / "=" / "/" )'. 
> I'll note that we *do* want to make sure that ";" isn't valid in the 
> session identifiers. On the other hand, implementors can simply take 
> the suggestions from RFC3548 section 4 instead, in which case the only 
> accommodation we would need to make is the equals sign.
>

considering that we treat the session identifier as opaque, it seems to 
me that the construction you describe would still not require escaping. 
Is this correct?

> /a


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


From simple-bounces@ietf.org  Fri Dec 17 18:05:25 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27347;
	Fri, 17 Dec 2004 18:05:25 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfRIr-0003EQ-7C; Fri, 17 Dec 2004 18:14:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfQru-00042e-AY; Fri, 17 Dec 2004 17:46:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfQip-0004d4-Jn
	for simple@megatron.ietf.org; Fri, 17 Dec 2004 17:37:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21860
	for <simple@ietf.org>; Fri, 17 Dec 2004 17:37:13 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQrY-0001Gl-7R
	for simple@ietf.org; Fri, 17 Dec 2004 17:46:16 -0500
Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHMWPtB006106
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 17 Dec 2004 16:32:25 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <41C15E4B.8090605@nokia.com>
References: <BDE51AB9.1F9C9%fluffy@cisco.com> <41C15E4B.8090605@nokia.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <87EC4912-507B-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Date: Fri, 17 Dec 2004 16:32:27 -0600
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        "simple@ietf.org" <simple@ietf.org>
Subject: [Simple] Re: MSRP: IANA considerations
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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit

I don't have a strong opinion on the meat of the matter, but I think we 
have discussed this in the past, and came up with a wg consensus not to 
have a registry. I don't think there are any new arguments here.

It is, of course, possible that I misremember.

On Dec 16, 2004, at 4:07 AM, Miguel Garcia wrote:

> I think the registry is mostly needed. It is a matter of time whether 
> you want to create the registry now or later. If the problem with 
> doing it now is the time IANA requires to do an action, then shouldn't 
> we start writing a I-D now that registers all this values? This way 
> the IANA registration will not be a head-of-line blocking for MSRP and 
> MSRP-relays.
>
> - Miguel
>
> Cullen Jennings wrote:
>
>> Don't know what others think but I don't think a registry is needed 
>> for any
>> of this. If later on there is great need for it, we could add it 
>> later (like
>> we did for SIP). I don't care greatly but don't want to clog IAN que 
>> with
>> stuff not critical.
>> On 12/13/04 6:14 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> 
>> wrote:
>>> About MSRP and the IANA considerations: I noticed that MSRP does not
>>> register any method, header, response code, etc. Then, MSRP relays 
>>> says
>>> in section 9 that there are no new requirements to IANA:
>>>
>>> Isn't this a bit mess without such registry? I would expect that MSRP
>>> follows a similar policy than SIP. I would expect MSRP to open a new
>>> MSRP registry with sub-registries for methods, headers, responses, 
>>> etc.
>>>
>>> Let's take MSRP-Relays. However, at least I have detected quite a few
>>> new "things" to be registered with IANA. Essentially, everything
>>> described under Section 4, "Overview of New Protocol Elements"
>>>
>>> - New method: AUTH
>>>
>>> - New headers: Use-Path, Authorization, WWW-Authenticate,
>>> Authentication-Info, Expires, Min-Expires, Max-Expires
>>>
>>> - New response code: 423 Out-of-bounds
>>>
>>> By the way: I am missing 401 Unauthorized from the above list in 
>>> Section 4.
>>>
>>> Don't you think it would be easier to establish a registry with all
>>> those sub-registries?
>>>
>>> Regards,
>>>
>>>           Miguel
>>>
>>>
>
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland


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


From simple-bounces@ietf.org  Fri Dec 17 18:22:30 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02846;
	Fri, 17 Dec 2004 18:22:30 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfRZN-0004u9-VJ; Fri, 17 Dec 2004 18:31:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfRBy-0006Rz-Gm; Fri, 17 Dec 2004 18:07:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfR74-00016U-BW
	for simple@megatron.ietf.org; Fri, 17 Dec 2004 18:02:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26283
	for <simple@ietf.org>; Fri, 17 Dec 2004 18:02:15 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfRFj-0002rK-Qh
	for simple@ietf.org; Fri, 17 Dec 2004 18:11:19 -0500
Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be
	forged)) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHN25b1008542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Dec 2004 17:02:06 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <41C3656D.4030402@nostrum.com>
Date: Fri, 17 Dec 2004 17:02:05 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] Re: MSRP URLs
References: <414FFFCF.8020007@nokia.com>	<92748F4C-13F0-11D9-B01C-000D93B0AE1A@nostrum.com>
	<415E6FE2.7000602@nokia.com> <41C09563.3010403@nostrum.com>
	<27A86F63-507C-11D9-B702-000D93B0AE1A@nostrum.com>
In-Reply-To: <27A86F63-507C-11D9-B702-000D93B0AE1A@nostrum.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: fluffy@cisco.com, Miguel Garcia <Miguel.An.Garcia@nokia.com>,
        SIMPLE mailing list <simple@ietf.org>, rohan@cisco.com
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit

Ben Campbell wrote:

>
> On Dec 15, 2004, at 1:49 PM, Adam Roach wrote:
>
>>
>> The only thing I can think of that might make us want to reconsider 
>> this would be the fact that relays may choose to do some kind 
>> encoding of session state in the session identifier. One logical 
>> (and, for many environments, trivial) encoding of such identifiers 
>> would be using base64 -- which includes the "+", "/", and "=" 
>> characters. So, we may want to relax the restriction to '1*( 
>> unreserved / "+" / "=" / "/" )'. I'll note that we *do* want to make 
>> sure that ";" isn't valid in the session identifiers. On the other 
>> hand, implementors can simply take the suggestions from RFC3548 
>> section 4 instead, in which case the only accommodation we would need 
>> to make is the equals sign.
>>
>
> considering that we treat the session identifier as opaque, it seems 
> to me that the construction you describe would still not require 
> escaping. Is this correct?


That is my understanding.

/a

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


From simple-bounces@ietf.org  Sat Dec 18 01:07:02 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06959;
	Sat, 18 Dec 2004 01:07:02 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfXsu-0008Rc-Ea; Sat, 18 Dec 2004 01:16:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfXhh-0000Zv-NF; Sat, 18 Dec 2004 01:04:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfXcP-0006xz-UI
	for simple@megatron.ietf.org; Sat, 18 Dec 2004 00:59:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06582
	for <simple@ietf.org>; Sat, 18 Dec 2004 00:59:02 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfXlB-0008FW-MM
	for simple@ietf.org; Sat, 18 Dec 2004 01:08:11 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 17 Dec 2004 23:05:46 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBI5wRdP021180;
	Fri, 17 Dec 2004 21:58:27 -0800 (PST)
Received: from cisco.com (rtp-vpn2-121.cisco.com [10.82.240.121])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANU66108;
	Sat, 18 Dec 2004 00:58:28 -0500 (EST)
Message-ID: <41C3C704.5070907@cisco.com>
Date: Sat, 18 Dec 2004 00:58:28 -0500
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] MSRP: sdp usage compared to BFCP
References: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>	<41BD853E.7070400@ericsson.com>
	<7EB139FB-5077-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        Robert Sparks <RjS@xten.com>,
        Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
        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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit

Ben,

I think MSRP should remain independent of comedia.
The reason is because the connection lifetime is often independent of a 
particular media session, which is quite different from comedia.

	Paul

Ben Campbell wrote:
> 
> On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:
> 
>>
>>> 1) BFCP depends on COMEDIA. MSRP does not.
>>> The reason MSRP does not invoke COMEDIA is mainly a historic one. At 
>>> the time we wrote that part of the spec, COMEDIA had not progressed 
>>> as far as it has now. Instead, MSRP states a default connection 
>>> "direction", and says that other mechanisms can be used to determine 
>>> direction once they become standardized.
>>
>>
>> The thing is that, most likely, comedia will be ready before both BFCP 
>> and MSRP. So, arguing that comedia will not be ready is not a valid 
>> argument anymore.
>>
>> Comedia defines two SDP attributes (setup and connection) that are 
>> used to figure out which end initiates the TCP connection and, on 
>> reception of a new offer, whether the TCP connection needs to be 
>> re-established or the existing TCP connection is OK.
>>
>> I do not think that using these attributes would add too much 
>> complexity to the protocol and having a way to know whether or not an 
>> offer implies that the TCP connection needs to be re-established but 
>> the rest of the parameters should not change seems like important 
>> funcionality. So, even if you want to avoid using the setup attribute 
>> (for some reason) by defining a default connection initiator, I 
>> believe you may still want to use the connection attribute.
>>
> 
> Technically, I agree that using comedia is a good idea. My concern now 
> is simply that every new thing we add is that much more delay in 
> completing MSRP. I don't think think it is trivial to add it, as the 
> presence of relays complicates things.  I see two possible ways to move 
> forward with this:
> 
> 1) Leave MSRP as is, and follow up shortly with a draft on how to use 
> COMEDIA with MSRP. I think this could be done in a backwards compatible 
> way, by saying that if the COMEDIA attributes are not present, it falls 
> back to the default behavior.
> 
> 2) Go ahead and add COMEDIA support to the base spec, with a small but 
> non-trivial delay while we make sure we don't break something.
> 
> Thoughts? (encouraged from anyone, but _particularly_ from the chairs...)
> 
> Ben.
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

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


From simple-bounces@ietf.org  Sat Dec 18 01:35:18 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08826;
	Sat, 18 Dec 2004 01:35:17 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfYKF-0000i2-5Q; Sat, 18 Dec 2004 01:44:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfY7y-00015B-Jf; Sat, 18 Dec 2004 01:31:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfY6j-0000jZ-RN
	for simple@megatron.ietf.org; Sat, 18 Dec 2004 01:30:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08413
	for <simple@ietf.org>; Sat, 18 Dec 2004 01:30:24 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfYFV-0000a3-Rv
	for simple@ietf.org; Sat, 18 Dec 2004 01:39:31 -0500
Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net
	[67.164.133.175]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBI6OGTr041222
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Sat, 18 Dec 2004 00:24:17 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <41C3C704.5070907@cisco.com>
References: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>	<41BD853E.7070400@ericsson.com>
	<7EB139FB-5077-11D9-B702-000D93B0AE1A@nostrum.com>
	<41C3C704.5070907@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <738D5B10-50BD-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] MSRP: sdp usage compared to BFCP
Date: Sat, 18 Dec 2004 00:24:20 -0600
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Robert Sparks <RjS@xten.com>,
        Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
        Simple WG <simple@ietf.org>, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit


On Dec 17, 2004, at 11:58 PM, Paul Kyzivat wrote:

> Ben,
>
> I think MSRP should remain independent of comedia.
> The reason is because the connection lifetime is often independent of 
> a particular media session, which is quite different from comedia.
>

Okay, I guess I should have listed that as an option 3. If we were to 
invoke comedia, we would have to very clear about connection 
management, and add things like the existence of a reuseable connection 
preempts comedia, as would the existence of other sessions using a 
connection when a session ends. That is partly why I think that 
integrating comedia is a non-trivial task.

> 	Paul
>
> Ben Campbell wrote:
>> On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:
>>>
>>>> 1) BFCP depends on COMEDIA. MSRP does not.
>>>> The reason MSRP does not invoke COMEDIA is mainly a historic one. 
>>>> At the time we wrote that part of the spec, COMEDIA had not 
>>>> progressed as far as it has now. Instead, MSRP states a default 
>>>> connection "direction", and says that other mechanisms can be used 
>>>> to determine direction once they become standardized.
>>>
>>>
>>> The thing is that, most likely, comedia will be ready before both 
>>> BFCP and MSRP. So, arguing that comedia will not be ready is not a 
>>> valid argument anymore.
>>>
>>> Comedia defines two SDP attributes (setup and connection) that are 
>>> used to figure out which end initiates the TCP connection and, on 
>>> reception of a new offer, whether the TCP connection needs to be 
>>> re-established or the existing TCP connection is OK.
>>>
>>> I do not think that using these attributes would add too much 
>>> complexity to the protocol and having a way to know whether or not 
>>> an offer implies that the TCP connection needs to be re-established 
>>> but the rest of the parameters should not change seems like 
>>> important funcionality. So, even if you want to avoid using the 
>>> setup attribute (for some reason) by defining a default connection 
>>> initiator, I believe you may still want to use the connection 
>>> attribute.
>>>
>> Technically, I agree that using comedia is a good idea. My concern 
>> now is simply that every new thing we add is that much more delay in 
>> completing MSRP. I don't think think it is trivial to add it, as the 
>> presence of relays complicates things.  I see two possible ways to 
>> move forward with this:
>> 1) Leave MSRP as is, and follow up shortly with a draft on how to use 
>> COMEDIA with MSRP. I think this could be done in a backwards 
>> compatible way, by saying that if the COMEDIA attributes are not 
>> present, it falls back to the default behavior.
>> 2) Go ahead and add COMEDIA support to the base spec, with a small 
>> but non-trivial delay while we make sure we don't break something.
>> Thoughts? (encouraged from anyone, but _particularly_ from the 
>> chairs...)
>> Ben.
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple


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


From simple-bounces@ietf.org  Sat Dec 18 02:59:59 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28673;
	Sat, 18 Dec 2004 02:59:58 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfZeD-0002oU-9q; Sat, 18 Dec 2004 03:09:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfZEe-0004IY-EQ; Sat, 18 Dec 2004 02:42:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfZ4B-0002Hw-1k
	for simple@megatron.ietf.org; Sat, 18 Dec 2004 02:31:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27001
	for <simple@ietf.org>; Sat, 18 Dec 2004 02:31:49 -0500 (EST)
Received: from albatross.ericsson.se ([193.180.251.49])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfZCy-00026R-1G
	for simple@ietf.org; Sat, 18 Dec 2004 02:40:56 -0500
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	iBI7VmvD016889
	for <simple@ietf.org>; Sat, 18 Dec 2004 08:31:48 +0100 (MET)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by
	esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Sat, 18 Dec 2004 08:31:47 +0100
Received: from ericsson.com (rvi2-94-187.sw.ericsson.se [153.88.94.187]) by
	esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id ZAPB0WK9; Sat, 18 Dec 2004 08:31:46 +0100
Message-ID: <41C3DCE1.7030801@ericsson.com>
Date: Sat, 18 Dec 2004 09:31:45 +0200
X-Sybari-Trust: cc12bec2 96d33411 c35e5ebf 00000138
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] MSRP: sdp usage compared to BFCP
References: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>	<41BD853E.7070400@ericsson.com>
	<7EB139FB-5077-11D9-B702-000D93B0AE1A@nostrum.com>
	<41C3C704.5070907@cisco.com>
	<738D5B10-50BD-11D9-B702-000D93B0AE1A@nostrum.com>
In-Reply-To: <738D5B10-50BD-11D9-B702-000D93B0AE1A@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Dec 2004 07:31:47.0181 (UTC)
	FILETIME=[A17D91D0:01C4E4D3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>,
        Simple WG <simple@ietf.org>, Robert Sparks <RjS@xten.com>,
        Paul Kyzivat <pkyzivat@cisco.com>, Joerg Ott <jo@tzi.uni-bremen.de>,
        Colin Perkins <csp@csperkins.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: 7bit

Hi,

cc:ing the MMUSIC chairs in case they have an opinion on this.

Colin, Joerg, the discussion is about whether or not MSRP should use
comedia. Ben is asking for chair advice on this.

Ben, Paul, could you further describe the scenario you have in mind? Is
it that two media sessions described by two different m lines use the
same TCP connection?

Regarding using default values so that we can add comedia in the future
in a backwards compatible manner, as Ben suggested, the default values
for the attributes in comedia are (quoting comedia):

    The default value of the setup attribute in an offer/answer exchange
    is 'active' in the offer and 'passive' in the answer.

    The default value of the connection attribute in both offers and
    answers is 'new'.

Did you have the same default values in mind?

Thanks,

Gonzalo



Ben Campbell wrote:

> 
> On Dec 17, 2004, at 11:58 PM, Paul Kyzivat wrote:
> 
>> Ben,
>> 
>> I think MSRP should remain independent of comedia. The reason is
>> because the connection lifetime is often independent of a
>> particular media session, which is quite different from comedia.
>> 
> 
> Okay, I guess I should have listed that as an option 3. If we were to
>  invoke comedia, we would have to very clear about connection
> management, and add things like the existence of a reuseable
> connection preempts comedia, as would the existence of other sessions
> using a connection when a session ends. That is partly why I think
> that integrating comedia is a non-trivial task.
> 
>> Paul
>> 
>> Ben Campbell wrote:
>> 
>>> On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:
>>> 
>>>> 
>>>>> 1) BFCP depends on COMEDIA. MSRP does not. The reason MSRP
>>>>> does not invoke COMEDIA is mainly a historic one. At the time
>>>>> we wrote that part of the spec, COMEDIA had not progressed as
>>>>> far as it has now. Instead, MSRP states a default connection
>>>>> "direction", and says that other mechanisms can be used to
>>>>> determine direction once they become standardized.
>>>> 
>>>> 
>>>> 
>>>> The thing is that, most likely, comedia will be ready before
>>>> both BFCP and MSRP. So, arguing that comedia will not be ready
>>>> is not a valid argument anymore.
>>>> 
>>>> Comedia defines two SDP attributes (setup and connection) that
>>>> are used to figure out which end initiates the TCP connection
>>>> and, on reception of a new offer, whether the TCP connection
>>>> needs to be re-established or the existing TCP connection is
>>>> OK.
>>>> 
>>>> I do not think that using these attributes would add too much 
>>>> complexity to the protocol and having a way to know whether or
>>>> not an offer implies that the TCP connection needs to be
>>>> re-established but the rest of the parameters should not change
>>>> seems like important funcionality. So, even if you want to
>>>> avoid using the setup attribute (for some reason) by defining a
>>>> default connection initiator, I believe you may still want to
>>>> use the connection attribute.
>>>> 
>>> Technically, I agree that using comedia is a good idea. My
>>> concern now is simply that every new thing we add is that much
>>> more delay in completing MSRP. I don't think think it is trivial
>>> to add it, as the presence of relays complicates things.  I see
>>> two possible ways to move forward with this: 1) Leave MSRP as is,
>>> and follow up shortly with a draft on how to use COMEDIA with
>>> MSRP. I think this could be done in a backwards compatible way,
>>> by saying that if the COMEDIA attributes are not present, it
>>> falls back to the default behavior. 2) Go ahead and add COMEDIA
>>> support to the base spec, with a small but non-trivial delay
>>> while we make sure we don't break something. Thoughts?
>>> (encouraged from anyone, but _particularly_ from the chairs...) 
>>> Ben. _______________________________________________ Simple
>>> mailing list Simple@ietf.org 
>>> https://www1.ietf.org/mailman/listinfo/simple



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


From simple-bounces@ietf.org  Sat Dec 18 10:20:10 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24556;
	Sat, 18 Dec 2004 10:20:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfgWH-0005E8-Nb; Sat, 18 Dec 2004 10:29:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfgML-0002Zo-OV; Sat, 18 Dec 2004 10:19:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfgKr-0001ug-FP; Sat, 18 Dec 2004 10:17:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24295;
	Sat, 18 Dec 2004 10:17:30 -0500 (EST)
Received: from bayc1-pasmtp03.bayc1.hotmail.com ([65.54.191.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfgTi-0005BQ-KC; Sat, 18 Dec 2004 10:26:43 -0500
Message-ID: <BAYC1-PASMTP0386E41DC19DFD4D1AD8D6EDA00@cez.ice>
X-Originating-IP: [64.228.36.149]
X-Originating-Email: [peter.ridler@sympatico.ca]
Received: from jedi ([64.228.36.149]) by bayc1-pasmtp03.bayc1.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); 
	Sat, 18 Dec 2004 07:16:52 -0800
From: "Peter Ridler" <ridler@softrac.ca>
To: "'Joerg Ott'" <jo@tzi.uni-bremen.de>,
        "'Colin Perkins'" <csp@csperkins.org>
Subject: RE: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
Date: Sat, 18 Dec 2004 10:16:12 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTkZthNP+O3Mc8CSVmztZ3kPs8N8wAq2WDw
In-Reply-To: <41BC325D.4010808@tzi.uni-bremen.de>
Message-ID: <BAYC1-PASMTP038v5tE00002aec@bayc1-pasmtp03.bayc1.hotmail.com>
X-OriginalArrivalTime: 18 Dec 2004 15:16:56.0365 (UTC)
	FILETIME=[9CA915D0:01C4E514]
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit
Cc: "'Simple WG'" <simple@ietf.org>, mmusic@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
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Content-Transfer-Encoding: 7bit


I also agree with Colin and Joerg.

I will also have two SDP parse engines (one for RTP and another for MSRP).
This will complicate the code.  Computers do not care about ugly formatting
--- overall performance should be the concern (I think all text formatted
protocols are a waste of network bandwidth and memory resources -- but I'm
stuck with them). 

We should follow the standards as best we can.  If the standard does not
meet your requirements then define/use another.

Another text based protocol is draft-ietf-sipping-toip-00.txt  This fits the
SIP/SDP model nicely.

Peter
 

> -----Original Message-----
> From: simple-bounces@ietf.org 
> [mailto:simple-bounces@ietf.org] On Behalf Of Joerg Ott
> Sent: Sunday, December 12, 2004 6:58 AM
> To: Colin Perkins
> Cc: Simple WG; mmusic@ietf.org
> Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
> 
> I agree with Colin on the ugliness issue of decomposing URLs 
> into c= and m= lines.  But this is the way SDP has worked and 
> works today.
> 
> The present discussion we are having here is about changing 
> SDP to for address/URL handling in one particular case.  This 
> does not strike me as something MSRP should be concerned with.
> 
> I would like to make one thing clear: we are either using 
> existing tools in another document or we are building new 
> ones.  There is nothing much in between.
> 
> Changing c=/m= semantics means changing SDP.  Just because 
> the syntax still looks the same does not mean that it is 
> still the same protocol.
> Any entity or generic protocol engine used to dealing with 
> SDP m=/c= would no longer do the right thing.
> 
> We see this kind of approach quite often -- by far too often 
> -- over the past years (just think the many "uses" of SIP 
> defined elsewhere, usually resulting in something "a little 
> but not entirely unlike" SIP).
> 
> What I would like avoid is having special treatment of SDP 
> depending on what the media type is (or other attributes signify).
> 
> Therefore, I strongly agree with Colin's conclusion: take SDP 
> as is or leave it altogether and pursue a different path.
> 
> Joerg
> 
> 
> Colin Perkins wrote:
> 
> > On 10 Dec 2004, at 21:41, Ben Campbell wrote:
> > 
> >> I really need to get closure on this, so I'd appreciate people 
> >> agreeing or disagreeing.
> >>
> >> I have had off-list correspondence indicating both 
> positions. In summary:
> >>
> >> In favor of the change, I had a comment to the effect that 
> changing 
> >> SDP semantics to ignore the C line and the port field on 
> the M line 
> >> really changes it to something that is no longer SDP, and 
> that such 
> >> deviations are in general bad for interop.
> >>
> >> In favor of leaving things as currently specified, I had 
> two comments 
> >> that decomposing URLs into the C and M lines is ugly, and 
> that having 
> >> a different mechanism to communicate endpoint addresses vs relay 
> >> addresses is really ugly.
> >>
> >> So, do people agree with one or the other position?
> > 
> > 
> > Decomposing the URL into the "c=" and "m=" lines is very ugly. 
> > Unfortunately, that ugliness is required if you want to use 
> SDP. This 
> > is why the SDPng work was started, to try to move to something less 
> > horrible...
> > 
> > Colin
> > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 
> 
> 
> _______________________________________________
> 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  Sat Dec 18 13:04:11 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05351;
	Sat, 18 Dec 2004 13:04:11 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cfj53-0008Sv-PV; Sat, 18 Dec 2004 13:13:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cfis3-0006Rq-4p; Sat, 18 Dec 2004 12:59:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfimF-0005b8-N6
	for simple@megatron.ietf.org; Sat, 18 Dec 2004 12:54:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04984
	for <simple@ietf.org>; Sat, 18 Dec 2004 12:53:56 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cfiv8-0008J7-Pa
	for simple@ietf.org; Sat, 18 Dec 2004 13:03:11 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 18 Dec 2004 11:00:47 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBIHrOHn023434;
	Sat, 18 Dec 2004 09:53:25 -0800 (PST)
Received: from cisco.com (rtp-vpn2-121.cisco.com [10.82.240.121])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANU77305;
	Sat, 18 Dec 2004 12:53:19 -0500 (EST)
Message-ID: <41C46E8F.9070407@cisco.com>
Date: Sat, 18 Dec 2004 12:53:19 -0500
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: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [Simple] MSRP: sdp usage compared to BFCP
References: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>	<41BD853E.7070400@ericsson.com>
	<7EB139FB-5077-11D9-B702-000D93B0AE1A@nostrum.com>
	<41C3C704.5070907@cisco.com>
	<738D5B10-50BD-11D9-B702-000D93B0AE1A@nostrum.com>
	<41C3DCE1.7030801@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Simple WG <simple@ietf.org>,
        Rohan Mahy <rohan@ekabal.com>, Robert Sparks <RjS@xten.com>,
        Joerg Ott <jo@tzi.uni-bremen.de>, Colin Perkins <csp@csperkins.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Content-Transfer-Encoding: 7bit



Gonzalo Camarillo wrote:
> Hi,
> 
> cc:ing the MMUSIC chairs in case they have an opinion on this.
> 
> Colin, Joerg, the discussion is about whether or not MSRP should use
> comedia. Ben is asking for chair advice on this.
> 
> Ben, Paul, could you further describe the scenario you have in mind? Is
> it that two media sessions described by two different m lines use the
> same TCP connection?

It could be two different m-lines in the same offer/answer, though that 
would probably be an unusual case.

A more plausible case is that the UA establishes multiple media 
sessions, either concurrently or sequentially, via independent 
offer/answer exchanges. A major use case for this would be a gateway to 
a different IM system. But an ordinary UA on a PC is likely to be in 
this situation too, because multiple concurrent chats are common.

The use of a common path doesn't mean talking to the same target - A 
common relay is all that is required.

We went to a lot of trouble to permit multiplexing multiple sessions on 
a single connection. Lets not mess it up now.

	Paul

> Regarding using default values so that we can add comedia in the future
> in a backwards compatible manner, as Ben suggested, the default values
> for the attributes in comedia are (quoting comedia):
> 
>    The default value of the setup attribute in an offer/answer exchange
>    is 'active' in the offer and 'passive' in the answer.
> 
>    The default value of the connection attribute in both offers and
>    answers is 'new'.
> 
> Did you have the same default values in mind?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> 
> Ben Campbell wrote:
> 
>>
>> On Dec 17, 2004, at 11:58 PM, Paul Kyzivat wrote:
>>
>>> Ben,
>>>
>>> I think MSRP should remain independent of comedia. The reason is
>>> because the connection lifetime is often independent of a
>>> particular media session, which is quite different from comedia.
>>>
>>
>> Okay, I guess I should have listed that as an option 3. If we were to
>>  invoke comedia, we would have to very clear about connection
>> management, and add things like the existence of a reuseable
>> connection preempts comedia, as would the existence of other sessions
>> using a connection when a session ends. That is partly why I think
>> that integrating comedia is a non-trivial task.
>>
>>> Paul
>>>
>>> Ben Campbell wrote:
>>>
>>>> On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:
>>>>
>>>>>
>>>>>> 1) BFCP depends on COMEDIA. MSRP does not. The reason MSRP
>>>>>> does not invoke COMEDIA is mainly a historic one. At the time
>>>>>> we wrote that part of the spec, COMEDIA had not progressed as
>>>>>> far as it has now. Instead, MSRP states a default connection
>>>>>> "direction", and says that other mechanisms can be used to
>>>>>> determine direction once they become standardized.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The thing is that, most likely, comedia will be ready before
>>>>> both BFCP and MSRP. So, arguing that comedia will not be ready
>>>>> is not a valid argument anymore.
>>>>>
>>>>> Comedia defines two SDP attributes (setup and connection) that
>>>>> are used to figure out which end initiates the TCP connection
>>>>> and, on reception of a new offer, whether the TCP connection
>>>>> needs to be re-established or the existing TCP connection is
>>>>> OK.
>>>>>
>>>>> I do not think that using these attributes would add too much 
>>>>> complexity to the protocol and having a way to know whether or
>>>>> not an offer implies that the TCP connection needs to be
>>>>> re-established but the rest of the parameters should not change
>>>>> seems like important funcionality. So, even if you want to
>>>>> avoid using the setup attribute (for some reason) by defining a
>>>>> default connection initiator, I believe you may still want to
>>>>> use the connection attribute.
>>>>>
>>>> Technically, I agree that using comedia is a good idea. My
>>>> concern now is simply that every new thing we add is that much
>>>> more delay in completing MSRP. I don't think think it is trivial
>>>> to add it, as the presence of relays complicates things.  I see
>>>> two possible ways to move forward with this: 1) Leave MSRP as is,
>>>> and follow up shortly with a draft on how to use COMEDIA with
>>>> MSRP. I think this could be done in a backwards compatible way,
>>>> by saying that if the COMEDIA attributes are not present, it
>>>> falls back to the default behavior. 2) Go ahead and add COMEDIA
>>>> support to the base spec, with a small but non-trivial delay
>>>> while we make sure we don't break something. Thoughts?
>>>> (encouraged from anyone, but _particularly_ from the chairs...) Ben. 
>>>> _______________________________________________ Simple
>>>> mailing list Simple@ietf.org 
>>>> https://www1.ietf.org/mailman/listinfo/simple
>>>
> 

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


From simple-bounces@ietf.org  Sat Dec 18 13:20:13 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06752;
	Sat, 18 Dec 2004 13:20:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfjKZ-0000NN-IE; Sat, 18 Dec 2004 13:29:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cfj6a-0001qQ-VY; Sat, 18 Dec 2004 13:15:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cfj4X-0000M6-AO; Sat, 18 Dec 2004 13:12:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06057;
	Sat, 18 Dec 2004 13:12:50 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfjDP-0000BS-O1; Sat, 18 Dec 2004 13:22:05 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 18 Dec 2004 10:16:59 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBIICHHn027276;
	Sat, 18 Dec 2004 10:12:18 -0800 (PST)
Received: from cisco.com (rtp-vpn2-121.cisco.com [10.82.240.121])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANU77671;
	Sat, 18 Dec 2004 13:12:15 -0500 (EST)
Message-ID: <41C472FF.7020308@cisco.com>
Date: Sat, 18 Dec 2004 13:12:15 -0500
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: Peter Ridler <ridler@softrac.ca>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
References: <BAYC1-PASMTP0386E41DC19DFD4D1AD8D6EDA00@cez.ice>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org, "'Joerg Ott'" <jo@tzi.uni-bremen.de>,
        "'Colin Perkins'" <csp@csperkins.org>, "'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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit



Peter Ridler wrote:
> I also agree with Colin and Joerg.
> 
> I will also have two SDP parse engines (one for RTP and another for MSRP).

Do you currently support anything but RTP?
How much do you expect to share between the two in the best case?

I don't think you are really talking about the parser - that isn't what 
is different. I think you are talking about implementing the connection 
semantics represented by the SDP. No matter what you do, these are 
different for RTP and MSRP.

The SDP parser that I have worked with is quite capable of handling this 
either way. It is only involved with the *syntax* of SDP.

Note that the syntax of SDP is already quite a mallable thing. Much of 
the important syntax is hidden in a-lines. MSRP has its own a-lines, and 
these need to be parsed in any case.

> This will complicate the code.  Computers do not care about ugly formatting
> --- overall performance should be the concern (I think all text formatted
> protocols are a waste of network bandwidth and memory resources -- but I'm
> stuck with them). 
> 
> We should follow the standards as best we can.  If the standard does not
> meet your requirements then define/use another.

Can you suggest what you have in mind?

Its not like this is an independent decision for MSRP. MSRP is intended 
to be negotiated via SIP. And it isn't a matter of mutual exclusion - 
negotiate MSRP with sip and something other than SDP, negotiate RPT with 
sip and SDP - I expect to be negotiating *both* MSRP and RPT with the 
same sip offer/answer exchange.

It seems you must have SDPng in mind. So you are suggesting we can't 
finish MSRP until the migration to SDPng is complete?

> Another text based protocol is draft-ietf-sipping-toip-00.txt  This fits the
> SIP/SDP model nicely.

It fits because it runs over RTP. It doesn't meet our requirements.

It feels like you are trying to make the SDP tail wag the SIP dog.

	Paul

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


From simple-bounces@ietf.org  Sun Dec 19 12:21:23 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15423;
	Sun, 19 Dec 2004 12:21:23 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4tO-0005wn-Eb; Sun, 19 Dec 2004 12:30:50 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg4bA-00011e-Ab; Sun, 19 Dec 2004 12:12:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4UE-0007vx-Ml
	for simple@megatron.ietf.org; Sun, 19 Dec 2004 12:04:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14619
	for <simple@ietf.org>; Sun, 19 Dec 2004 12:04:47 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4dK-0005d5-8h
	for simple@ietf.org; Sun, 19 Dec 2004 12:14:14 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2004 09:09:10 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBJH4HHn028721;
	Sun, 19 Dec 2004 09:04:18 -0800 (PST)
Received: from [10.242.56.116] (sjc-vpn7-229.cisco.com [10.21.144.229])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW62362;
	Sun, 19 Dec 2004 09:04:16 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 18 Dec 2004 12:27:21 -0800
Subject: Re: [Simple] Re: MSRP: Report-Failure partial
From: Cullen Jennings <fluffy@cisco.com>
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Message-ID: <BDE9D2A9.2019C%fluffy@cisco.com>
In-Reply-To: <41C15DD7.10604@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: 7bit
Cc: Rohan Mahy <rohan@ekabal.com>, "simple@ietf.org" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Content-Transfer-Encoding: 7bit


ok - I added some text like that -  will be in next version. More inline

On 12/16/04 2:05 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:

> Cullen:
> 
> The explanation about partial looks good. I would welcome this kind of
> discussion written in the base draft, it will certainly help to
> understand things better.
> 
> - Miguel
> 
> Cullen Jennings wrote:
> 
>> The goal of "partial" was to report errors except timeouts. The timeout
>> require the sending hop to run a timer and that receiving hop to send an
>> acknowledgement to stop the timer. Some systems don't want the overhead of
>> doing this so choose not to but still report other errors.
>> 
>> We may have the text messed up to describe this.
>> 
>> On 12/14/04 4:53 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:
>> 
>> 
>>> Hi:
>>> 
>>> I am trying to understand the concise procedures that affect the
>>> Report-Failure: partial in MSRP, and I think I am missing something.
>>> 
>>> On reading the MSRP draft I found contradictory text:
>>> 
>>> - Second paragraph on 7.1.3 says:
>>> 
>>>    If the endpoint receives a SEND request with a Report-Failure header
>>>    field ...  "partial", it MUST NOT send a transaction response to the
>>>    request, but SHOULD send an appropriate non-200 class response a
>>>    failure occurs.
>>> 
>>> So I understand that "partial" means "don't send 200, but send any other
>>> response".
>>> 
>>> - Section 7.3 says:
>>> 
>>>    When the
>>>    request is received, the To-Path will have exactly one URL, which
>>>    MUST map to an existing session that is associated with the
>>>    connection on which the request arrived.  If this is not true, and
>>>    the request contained a Report-Failure header value of "no" or
>>>    "partial", then the receiver SHOULD quietly ignore the request.  If
>>>    the Report-Failure header is not present, or had a value of "yes",
>>>    then the receiver MUST return a 481 response.
>>> 
>>> Here the text says that "partial" means don't send a 481 response, which
>>> is obviously in contradiction with 7.1.3.
This is wrong - will fix  - have changed to

If this is not true then the receiver MUST generate an 481 error and ignore
the
request. Note that if the Failure-Report header had a value of "no", then no
error report would be sent.

>>> 
>>> - Section 7.3.1 then says.
>>> 
>>>    If the SEND request contained a Content-Type header field indicating
>>>    an unsupported MIME type, the receiver SHOULD send a 415 response or
>>>    failure report, as appropriate for the Report-Failure header field
>>>    value.
>>> 
>>> That is misleading me in another aspect: by reading the above text I may
>>> think that the Report-Failure header field value determines whether and
>>> endpoint sends failure responses or REPORT requests. So one could think
>>> that "Report-Failure: yes" means send REPORt requests rather than
>>> failure responses, whereas "Report-Failure: no" means the opposite. I
>>> believe this is not the intention, right?
>>> 

Yep - clear as mud :-) How about

If the SEND request contained a Content-Type header field indicating an
unsupported MIME type, the receiver MUST generate a failure report with a
415 error code. Note that this failure report will not be sent if the
Report-Failure header contains a value of "no".

>>> So is this something that can be further clarified in the document?
>>> 
>>> Regards,
>>> 
>>> 
>>>         Miguel
>>> 
>>> 
>> 
>> 


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


From simple-bounces@ietf.org  Sun Dec 19 12:22:07 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15551;
	Sun, 19 Dec 2004 12:22:07 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4u5-0005y3-4F; Sun, 19 Dec 2004 12:31:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg4bA-00011q-PJ; Sun, 19 Dec 2004 12:12:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4UF-0007xf-BX
	for simple@megatron.ietf.org; Sun, 19 Dec 2004 12:04:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14624
	for <simple@ietf.org>; Sun, 19 Dec 2004 12:04:48 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4dK-0005d6-RB
	for simple@ietf.org; Sun, 19 Dec 2004 12:14:15 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2004 09:09:11 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBJH4IHn028727;
	Sun, 19 Dec 2004 09:04:19 -0800 (PST)
Received: from [10.242.56.116] (sjc-vpn7-229.cisco.com [10.21.144.229])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW62363;
	Sun, 19 Dec 2004 09:04:17 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 18 Dec 2004 12:51:17 -0800
Subject: Re: [Simple] Re: MSRP: IANA considerations
From: Cullen Jennings <fluffy@cisco.com>
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Message-ID: <BDE9D845.2019D%fluffy@cisco.com>
In-Reply-To: <41C15E4B.8090605@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Cc: Rohan Mahy <rohan@ekabal.com>, "simple@ietf.org" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit


I'm really happy to "do the right thing" here - just not sure what that is
and could easily go either way. I agree that if we need IANA to do something
and IANA can't, then we ought to go fix IANA. I started a thread on the ietf
mailing list to see if we can get a little concrete advice on what to do.


On 12/16/04 2:07 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:

> I think the registry is mostly needed. It is a matter of time whether
> you want to create the registry now or later. If the problem with doing
> it now is the time IANA requires to do an action, then shouldn't we
> start writing a I-D now that registers all this values? This way the
> IANA registration will not be a head-of-line blocking for MSRP and
> MSRP-relays.
> 
> - Miguel
> 
> Cullen Jennings wrote:
> 
>> Don't know what others think but I don't think a registry is needed for any
>> of this. If later on there is great need for it, we could add it later (like
>> we did for SIP). I don't care greatly but don't want to clog IAN que with
>> stuff not critical.
>> 
>> 
>> 
>> On 12/13/04 6:14 AM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:
>> 
>> 
>>> About MSRP and the IANA considerations: I noticed that MSRP does not
>>> register any method, header, response code, etc. Then, MSRP relays says
>>> in section 9 that there are no new requirements to IANA:
>>> 
>>> Isn't this a bit mess without such registry? I would expect that MSRP
>>> follows a similar policy than SIP. I would expect MSRP to open a new
>>> MSRP registry with sub-registries for methods, headers, responses, etc.
>>> 
>>> Let's take MSRP-Relays. However, at least I have detected quite a few
>>> new "things" to be registered with IANA. Essentially, everything
>>> described under Section 4, "Overview of New Protocol Elements"
>>> 
>>> - New method: AUTH
>>> 
>>> - New headers: Use-Path, Authorization, WWW-Authenticate,
>>> Authentication-Info, Expires, Min-Expires, Max-Expires
>>> 
>>> - New response code: 423 Out-of-bounds
>>> 
>>> By the way: I am missing 401 Unauthorized from the above list in Section 4.
>>> 
>>> Don't you think it would be easier to establish a registry with all
>>> those sub-registries?
>>> 
>>> Regards,
>>> 
>>>           Miguel
>>> 
>>> 
>> 
>> 


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


From simple-bounces@ietf.org  Sun Dec 19 12:23:41 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15815;
	Sun, 19 Dec 2004 12:23:41 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4v3-0005zn-2X; Sun, 19 Dec 2004 12:33:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg4bB-000128-C3; Sun, 19 Dec 2004 12:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4UG-0007yi-8j
	for simple@megatron.ietf.org; Sun, 19 Dec 2004 12:04:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14633
	for <simple@ietf.org>; Sun, 19 Dec 2004 12:04:49 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4dK-0005d5-Rt
	for simple@ietf.org; Sun, 19 Dec 2004 12:14:16 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2004 09:09:13 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBJH4GdP009389;
	Sun, 19 Dec 2004 09:04:17 -0800 (PST)
Received: from [10.242.56.116] (sjc-vpn7-229.cisco.com [10.21.144.229])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW62365;
	Sun, 19 Dec 2004 09:04:18 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 18 Dec 2004 13:00:13 -0800
Subject: Re: [Simple] Re: MSRP URLs
From: Cullen Jennings <fluffy@cisco.com>
To: Adam Roach <adam@nostrum.com>, Ben Campbell <ben@nostrum.com>
Message-ID: <BDE9DA5D.2019F%fluffy@cisco.com>
In-Reply-To: <41C3656D.4030402@nostrum.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>, rohan@cisco.com,
        "simple@ietf.org" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit


I'm lost on this thread - do I need to got fix any text?


On 12/17/04 3:02 PM, "Adam Roach" <adam@nostrum.com> wrote:

> Ben Campbell wrote:
> 
>> 
>> On Dec 15, 2004, at 1:49 PM, Adam Roach wrote:
>> 
>>> 
>>> The only thing I can think of that might make us want to reconsider
>>> this would be the fact that relays may choose to do some kind
>>> encoding of session state in the session identifier. One logical
>>> (and, for many environments, trivial) encoding of such identifiers
>>> would be using base64 -- which includes the "+", "/", and "="
>>> characters. So, we may want to relax the restriction to '1*(
>>> unreserved / "+" / "=" / "/" )'. I'll note that we *do* want to make
>>> sure that ";" isn't valid in the session identifiers. On the other
>>> hand, implementors can simply take the suggestions from RFC3548
>>> section 4 instead, in which case the only accommodation we would need
>>> to make is the equals sign.
>>> 
>> 
>> considering that we treat the session identifier as opaque, it seems
>> to me that the construction you describe would still not require
>> escaping. Is this correct?
> 
> 
> That is my understanding.
> 
> /a
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


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


From simple-bounces@ietf.org  Sun Dec 19 12:23:50 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15851;
	Sun, 19 Dec 2004 12:23:50 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4vl-000620-Bz; Sun, 19 Dec 2004 12:33:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg4bC-000136-3Y; Sun, 19 Dec 2004 12:12:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4UG-0007yk-VB
	for simple@megatron.ietf.org; Sun, 19 Dec 2004 12:04:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14638
	for <simple@ietf.org>; Sun, 19 Dec 2004 12:04:49 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4dL-0005d6-DI
	for simple@ietf.org; Sun, 19 Dec 2004 12:14:16 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2004 09:09:14 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBJH4Lo9023227;
	Sun, 19 Dec 2004 09:04:22 -0800 (PST)
Received: from [10.242.56.116] (sjc-vpn7-229.cisco.com [10.21.144.229])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW62367;
	Sun, 19 Dec 2004 09:04:19 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 18 Dec 2004 13:13:24 -0800
Subject: Re: [Simple] MSRP: sdp usage compared to BFCP
From: Cullen Jennings <fluffy@cisco.com>
To: Paul H Kyzivat <pkyzivat@cisco.com>,
        "gonzalo.camarillo@ericsson.com" <Gonzalo.Camarillo@ericsson.com>
Message-ID: <BDE9DD74.201A1%fluffy@cisco.com>
In-Reply-To: <41C46E8F.9070407@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Content-Transfer-Encoding: 7bit
Cc: Rohan Mahy <rohan@ekabal.com>, Colin Perkins <csp@csperkins.org>,
        Joerg Ott <jo@tzi.uni-bremen.de>, "simple@ietf.org" <simple@ietf.org>,
        Robert Sparks <RjS@xten.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
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Content-Transfer-Encoding: 7bit


I really don't follow how this comedia stuff is related to MSRP. I think we
have it really confused.

Let's first consider a case with relays. If alice and bob sends some offers
and answers back and forth, the topic of if they will set up new TCP
connections to the relays it totally independent of anything in the offers
or answers. If they have existing TCP connections to the relays they use the
existing connections. Similarly in the case with no relays - if a useable
connection exists, you use it. If were to add comedia somehow to the offer
answers stuff  - MSRP would explicitly say to ignore it if it told you to
set up a new connection. This was a key design constraint so that the the
congestion control properties of TCP would not be lost by opening an
arbitrary number of connections.

The fundamental reason comedia is not relevant to MSRP is that comedia is
about setting up a TCP connection for a particular media stream. MSRP is
based on setting up a path that is multiplexed over a single TCP connection
and the lifetime of the TCP connection is not bound to the lifetime of
sessions that are set up in the offer answer.





On 12/18/04 9:53 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

> 
> 
> Gonzalo Camarillo wrote:
>> Hi,
>> 
>> cc:ing the MMUSIC chairs in case they have an opinion on this.
>> 
>> Colin, Joerg, the discussion is about whether or not MSRP should use
>> comedia. Ben is asking for chair advice on this.
>> 
>> Ben, Paul, could you further describe the scenario you have in mind? Is
>> it that two media sessions described by two different m lines use the
>> same TCP connection?
> 
> It could be two different m-lines in the same offer/answer, though that
> would probably be an unusual case.
> 
> A more plausible case is that the UA establishes multiple media
> sessions, either concurrently or sequentially, via independent
> offer/answer exchanges. A major use case for this would be a gateway to
> a different IM system. But an ordinary UA on a PC is likely to be in
> this situation too, because multiple concurrent chats are common.
> 
> The use of a common path doesn't mean talking to the same target - A
> common relay is all that is required.
> 
> We went to a lot of trouble to permit multiplexing multiple sessions on
> a single connection. Lets not mess it up now.
> 
> Paul
> 
>> Regarding using default values so that we can add comedia in the future
>> in a backwards compatible manner, as Ben suggested, the default values
>> for the attributes in comedia are (quoting comedia):
>> 
>>    The default value of the setup attribute in an offer/answer exchange
>>    is 'active' in the offer and 'passive' in the answer.
>> 
>>    The default value of the connection attribute in both offers and
>>    answers is 'new'.
>> 
>> Did you have the same default values in mind?
>> 
>> Thanks,
>> 
>> Gonzalo
>> 
>> 
>> 
>> Ben Campbell wrote:
>> 
>>> 
>>> On Dec 17, 2004, at 11:58 PM, Paul Kyzivat wrote:
>>> 
>>>> Ben,
>>>> 
>>>> I think MSRP should remain independent of comedia. The reason is
>>>> because the connection lifetime is often independent of a
>>>> particular media session, which is quite different from comedia.
>>>> 
>>> 
>>> Okay, I guess I should have listed that as an option 3. If we were to
>>>  invoke comedia, we would have to very clear about connection
>>> management, and add things like the existence of a reuseable
>>> connection preempts comedia, as would the existence of other sessions
>>> using a connection when a session ends. That is partly why I think
>>> that integrating comedia is a non-trivial task.
>>> 
>>>> Paul
>>>> 
>>>> Ben Campbell wrote:
>>>> 
>>>>> On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:
>>>>> 
>>>>>> 
>>>>>>> 1) BFCP depends on COMEDIA. MSRP does not. The reason MSRP
>>>>>>> does not invoke COMEDIA is mainly a historic one. At the time
>>>>>>> we wrote that part of the spec, COMEDIA had not progressed as
>>>>>>> far as it has now. Instead, MSRP states a default connection
>>>>>>> "direction", and says that other mechanisms can be used to
>>>>>>> determine direction once they become standardized.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The thing is that, most likely, comedia will be ready before
>>>>>> both BFCP and MSRP. So, arguing that comedia will not be ready
>>>>>> is not a valid argument anymore.
>>>>>> 
>>>>>> Comedia defines two SDP attributes (setup and connection) that
>>>>>> are used to figure out which end initiates the TCP connection
>>>>>> and, on reception of a new offer, whether the TCP connection
>>>>>> needs to be re-established or the existing TCP connection is
>>>>>> OK.
>>>>>> 
>>>>>> I do not think that using these attributes would add too much
>>>>>> complexity to the protocol and having a way to know whether or
>>>>>> not an offer implies that the TCP connection needs to be
>>>>>> re-established but the rest of the parameters should not change
>>>>>> seems like important funcionality. So, even if you want to
>>>>>> avoid using the setup attribute (for some reason) by defining a
>>>>>> default connection initiator, I believe you may still want to
>>>>>> use the connection attribute.
>>>>>> 
>>>>> Technically, I agree that using comedia is a good idea. My
>>>>> concern now is simply that every new thing we add is that much
>>>>> more delay in completing MSRP. I don't think think it is trivial
>>>>> to add it, as the presence of relays complicates things.  I see
>>>>> two possible ways to move forward with this: 1) Leave MSRP as is,
>>>>> and follow up shortly with a draft on how to use COMEDIA with
>>>>> MSRP. I think this could be done in a backwards compatible way,
>>>>> by saying that if the COMEDIA attributes are not present, it
>>>>> falls back to the default behavior. 2) Go ahead and add COMEDIA
>>>>> support to the base spec, with a small but non-trivial delay
>>>>> while we make sure we don't break something. Thoughts?
>>>>> (encouraged from anyone, but _particularly_ from the chairs...) Ben.
>>>>> _______________________________________________ Simple
>>>>> mailing list Simple@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/simple
>>>> 
>> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


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


From simple-bounces@ietf.org  Sun Dec 19 12:25:34 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16044;
	Sun, 19 Dec 2004 12:25:34 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4xQ-00064z-Cs; Sun, 19 Dec 2004 12:35:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg4bC-00013S-Qz; Sun, 19 Dec 2004 12:12:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4UI-0007ym-66
	for simple@megatron.ietf.org; Sun, 19 Dec 2004 12:04:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14645
	for <simple@ietf.org>; Sun, 19 Dec 2004 12:04:51 -0500 (EST)
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.33)
	id 1Cg4dM-0005d8-Mr
	for simple@ietf.org; Sun, 19 Dec 2004 12:14:18 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-1.cisco.com with ESMTP; 19 Dec 2004 09:10:57 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBJH4JHn028735;
	Sun, 19 Dec 2004 09:04:20 -0800 (PST)
Received: from [10.242.56.116] (sjc-vpn7-229.cisco.com [10.21.144.229])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW62364;
	Sun, 19 Dec 2004 09:04:18 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 18 Dec 2004 12:54:42 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Rohan Mahy <rohan@ekabal.com>
Message-ID: <BDE9D912.2019E%fluffy@cisco.com>
In-Reply-To: <41C1F082.3050405@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>
Subject: [Simple] Re: MSRP-relays and HTTP Digest authentication
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
X-Spam-Score: 0.4 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit


Good point - I agree. I think it is just the final destination so the URI
used in digest calculation. So it should be the last URI in the To-Path
header. I will fix the text.


On 12/16/04 12:30 PM, "Miguel Garcia" <Miguel.An.Garcia@nokia.com> wrote:

> Hi:
> 
> I think there is also something that deserves a bit more of discussion:
> the usage of HTTP Digest authentication in MSRP-relays.
> 
> An HTTP Digest response contains a checksum of the username, password,
> nonce, the method and the requested URI. Unlinke HTTP, MSRP does not
> offer the concept of the Request-URI. So is it the To-Path what we want
> to protect in the Digest checksum? The MSRP To-Path is the most similar
> thing to the HTTP Request-URI.
> 
> Note that the MSRP relays draft indicates in Section 8.1:
> 
>     Note that unlike
>     in some usages of HTTP Authentication (for example, SIP), the uri
>     parameter in the Authorize header is the same as the Request-URI in
>     the request line of the MSRP parcel of the AUTH request.
> 
> which is the parragraph that requires further discussion.
> 
> - Miguel


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


From simple-bounces@ietf.org  Sun Dec 19 12:27:28 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16130;
	Sun, 19 Dec 2004 12:27:27 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4zH-00067d-1U; Sun, 19 Dec 2004 12:36:55 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg4pQ-0005VN-H1; Sun, 19 Dec 2004 12:26:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4f3-0002Ns-EV
	for simple@megatron.ietf.org; Sun, 19 Dec 2004 12:16:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15145
	for <simple@ietf.org>; Sun, 19 Dec 2004 12:15:58 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg4o5-0005pe-2R
	for simple@ietf.org; Sun, 19 Dec 2004 12:25:25 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2004 09:20:15 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBJHFNHn000459;
	Sun, 19 Dec 2004 09:15:24 -0800 (PST)
Received: from [10.242.56.116] (sjc-vpn7-229.cisco.com [10.21.144.229])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW62553;
	Sun, 19 Dec 2004 09:15:22 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sun, 19 Dec 2004 09:15:21 -0800
Subject: Re: [Simple] Re: MSRP URLs
From: Cullen Jennings <fluffy@cisco.com>
To: Adam Roach <adam@nostrum.com>, Ben Campbell <ben@nostrum.com>
Message-ID: <BDEAF729.20223%fluffy@cisco.com>
In-Reply-To: <BDE9DA5D.2019F%fluffy@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Rohan Mahy <rohan@ekabal.com>,
        "simple@ietf.org" <simple@ietf.org>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit


Just fixed Rohan's email address on this thread - pleaser reply to this one.

On 12/18/04 1:00 PM, "Cullen Jennings" <fluffy@cisco.com> wrote:

> 
> I'm lost on this thread - do I need to got fix any text?
> 
> 
> On 12/17/04 3:02 PM, "Adam Roach" <adam@nostrum.com> wrote:
> 
>> Ben Campbell wrote:
>> 
>>> 
>>> On Dec 15, 2004, at 1:49 PM, Adam Roach wrote:
>>> 
>>>> 
>>>> The only thing I can think of that might make us want to reconsider
>>>> this would be the fact that relays may choose to do some kind
>>>> encoding of session state in the session identifier. One logical
>>>> (and, for many environments, trivial) encoding of such identifiers
>>>> would be using base64 -- which includes the "+", "/", and "="
>>>> characters. So, we may want to relax the restriction to '1*(
>>>> unreserved / "+" / "=" / "/" )'. I'll note that we *do* want to make
>>>> sure that ";" isn't valid in the session identifiers. On the other
>>>> hand, implementors can simply take the suggestions from RFC3548
>>>> section 4 instead, in which case the only accommodation we would need
>>>> to make is the equals sign.
>>>> 
>>> 
>>> considering that we treat the session identifier as opaque, it seems
>>> to me that the construction you describe would still not require
>>> escaping. Is this correct?
>> 
>> 
>> That is my understanding.
>> 
>> /a
>> 
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple


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


From simple-bounces@ietf.org  Sun Dec 19 14:49:57 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25539;
	Sun, 19 Dec 2004 14:49:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg7DA-0000Nv-WF; Sun, 19 Dec 2004 14:59:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg72N-0006Jy-FW; Sun, 19 Dec 2004 14:48:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg6uA-0005go-OP
	for simple@megatron.ietf.org; Sun, 19 Dec 2004 14:39:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24200
	for <simple@ietf.org>; Sun, 19 Dec 2004 14:39:44 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cg73G-00005o-Oq
	for simple@ietf.org; Sun, 19 Dec 2004 14:49:12 -0500
Received: from [192.168.0.108] (adsl-209-30-64-8.dsl.rcsntx.swbell.net
	[209.30.64.8]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBJJaq0R091654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 19 Dec 2004 13:36:53 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <41C5D853.9010008@nostrum.com>
Date: Sun, 19 Dec 2004 13:36:51 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Simple] Re: MSRP URLs
References: <BDEAF729.20223%fluffy@cisco.com>
In-Reply-To: <BDEAF729.20223%fluffy@cisco.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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>,
        "simple@ietf.org" <simple@ietf.org>, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit

Cullen Jennings wrote:

>I'm lost on this thread - do I need to got fix any text?
>

Not in the relay draft, no. The only impacts I would see would be in the 
base draft. I assume that, if there are no objections, Ben will modify 
the list of allowed characters to include +, /, and =.

/a

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


From simple-bounces@ietf.org  Sun Dec 19 17:51:18 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17013;
	Sun, 19 Dec 2004 17:51:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgA2h-0005Or-Q3; Sun, 19 Dec 2004 18:00:48 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg9ib-0003QB-AR; Sun, 19 Dec 2004 17:40:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cg9hd-0003FA-DN; Sun, 19 Dec 2004 17:39:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16292;
	Sun, 19 Dec 2004 17:38:58 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cg9ql-00057l-T0; Sun, 19 Dec 2004 17:48:28 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 19 Dec 2004 15:46:02 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBJMcQHn021734;
	Sun, 19 Dec 2004 14:38:27 -0800 (PST)
Received: from [66.103.196.117] (sjc-vpn4-290.cisco.com [10.21.81.34])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW66663;
	Sun, 19 Dec 2004 14:38:24 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sun, 19 Dec 2004 14:38:22 -0800
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
From: Cullen Jennings <fluffy@cisco.com>
To: Peter Ridler <ridler@softrac.ca>, "'Joerg Ott'" <jo@tzi.uni-bremen.de>,
        "'Colin Perkins'" <csp@csperkins.org>
Message-ID: <BDEB42DE.2025D%fluffy@cisco.com>
In-Reply-To: <BAYC1-PASMTP0386E41DC19DFD4D1AD8D6EDA00@cez.ice>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>, "mmusic@ietf.org" <mmusic@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: 7bit


I think that the MSRP folks have not clearly explained what we want to do in
SDP. We want to set up a path of multiple addresses, not just a single
address for one far end. That the protocol uses TCP or that it transports
text instead of audio I don't think should cause it to be much different.


On 12/18/04 7:16 AM, "Peter Ridler" <ridler@softrac.ca> wrote:

> 
> I also agree with Colin and Joerg.
> 
> I will also have two SDP parse engines (one for RTP and another for MSRP).
> This will complicate the code.  Computers do not care about ugly formatting
> --- overall performance should be the concern (I think all text formatted
> protocols are a waste of network bandwidth and memory resources -- but I'm
> stuck with them).
> 
> We should follow the standards as best we can.  If the standard does not
> meet your requirements then define/use another.
> 
> Another text based protocol is draft-ietf-sipping-toip-00.txt  This fits the
> SIP/SDP model nicely.
> 
> Peter
>  
> 
>> -----Original Message-----
>> From: simple-bounces@ietf.org
>> [mailto:simple-bounces@ietf.org] On Behalf Of Joerg Ott
>> Sent: Sunday, December 12, 2004 6:58 AM
>> To: Colin Perkins
>> Cc: Simple WG; mmusic@ietf.org
>> Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
>> 
>> I agree with Colin on the ugliness issue of decomposing URLs
>> into c= and m= lines.  But this is the way SDP has worked and
>> works today.
>> 
>> The present discussion we are having here is about changing
>> SDP to for address/URL handling in one particular case.  This
>> does not strike me as something MSRP should be concerned with.
>> 
>> I would like to make one thing clear: we are either using
>> existing tools in another document or we are building new
>> ones.  There is nothing much in between.
>> 
>> Changing c=/m= semantics means changing SDP.  Just because
>> the syntax still looks the same does not mean that it is
>> still the same protocol.
>> Any entity or generic protocol engine used to dealing with
>> SDP m=/c= would no longer do the right thing.
>> 
>> We see this kind of approach quite often -- by far too often
>> -- over the past years (just think the many "uses" of SIP
>> defined elsewhere, usually resulting in something "a little
>> but not entirely unlike" SIP).
>> 
>> What I would like avoid is having special treatment of SDP
>> depending on what the media type is (or other attributes signify).
>> 
>> Therefore, I strongly agree with Colin's conclusion: take SDP
>> as is or leave it altogether and pursue a different path.
>> 
>> Joerg
>> 
>> 
>> Colin Perkins wrote:
>> 
>>> On 10 Dec 2004, at 21:41, Ben Campbell wrote:
>>> 
>>>> I really need to get closure on this, so I'd appreciate people
>>>> agreeing or disagreeing.
>>>> 
>>>> I have had off-list correspondence indicating both
>> positions. In summary:
>>>> 
>>>> In favor of the change, I had a comment to the effect that
>> changing 
>>>> SDP semantics to ignore the C line and the port field on
>> the M line 
>>>> really changes it to something that is no longer SDP, and
>> that such 
>>>> deviations are in general bad for interop.
>>>> 
>>>> In favor of leaving things as currently specified, I had
>> two comments 
>>>> that decomposing URLs into the C and M lines is ugly, and
>> that having 
>>>> a different mechanism to communicate endpoint addresses vs relay
>>>> addresses is really ugly.
>>>> 
>>>> So, do people agree with one or the other position?
>>> 
>>> 
>>> Decomposing the URL into the "c=" and "m=" lines is very ugly.
>>> Unfortunately, that ugliness is required if you want to use
>> SDP. This 
>>> is why the SDPng work was started, to try to move to something less
>>> horrible...
>>> 
>>> Colin
>>> 
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>> 
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


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


From simple-bounces@ietf.org  Mon Dec 20 02:55:30 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08483;
	Mon, 20 Dec 2004 02:55:30 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgIXP-000170-Mn; Mon, 20 Dec 2004 03:05:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgIM8-0000tw-SK; Mon, 20 Dec 2004 02:53:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgIIw-0000Bb-Hk; Mon, 20 Dec 2004 02:50:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08228;
	Mon, 20 Dec 2004 02:50:05 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgIS8-0000xp-Tb; Mon, 20 Dec 2004 02:59:38 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2004 23:54:31 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBK7nSdP014918;
	Sun, 19 Dec 2004 23:49:28 -0800 (PST)
Received: from [192.168.1.101] (che-vpn-cluster-2-23.cisco.com [10.86.242.23])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGL19154;
	Sun, 19 Dec 2004 23:49:29 -0800 (PST)
Message-ID: <41C68408.4030707@cisco.com>
Date: Mon, 20 Dec 2004 02:49:28 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Geopriv] Re: [Simple] Usage
	of	substitution	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>	<41C02A85.3050608@nokia.com>
	<41C056C8.5070400@cisco.com>	<41C0AC71.3060001@cs.columbia.edu>
	<41C2B529.40807@nokia.com>
In-Reply-To: <41C2B529.40807@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
        Simple WG <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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit

inline.

Jari Urpalainen wrote:

> ext Henning Schulzrinne wrote:
> 
>> As an additional datapoint:
>>
>> http://www.w3.org/TR/xmlschema-0/
>>
>> says (Section 5.5):
>>
>> "The lax  value of the processContents  attribute instructs an XML 
>> processor to validate the element content on a can-do basis: It will 
>> validate elements and attributes for which it can obtain schema 
>> information, but it will not signal errors for those it cannot obtain 
>> any schema information."
>>
>> That seems roughly what we want, with the exception of not being able 
>> to constrain the positioning of elements noted below.
>>
> If there's only a single extension point then also this positioning 
> problem vanishes. However, I still have a problem understanding 
> (regarding common-policy) "what we want" as I can't see any problem with 
> the current draft besides perhaps the usefulness of Content-Type 
> registration which is imo needed in presence-rules instead.

The problem case I am worried about is the following.

We are using xcap. A client is managing its presence authorization 
policies. It attempts to upload a document to the server. The client is 
made from a different vendor from the server, and has recently been 
upgraded to support a new permission type. This new permission is not 
understood by the server.

As currently defined, since xcap servers have to do xml validation, the 
user will not be able to upload its permissions. I believe it should be 
able to do so. We have designed the common-policy work to be "privacy 
safe" so even if permissions unknown to the server are included, 
additional information can never be leaked.

-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 Dec 20 03:45:16 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11288;
	Mon, 20 Dec 2004 03:45:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgJJa-0002BJ-3i; Mon, 20 Dec 2004 03:54:50 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgJ8U-0006zF-70; Mon, 20 Dec 2004 03:43:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJ7Z-0006nM-R8
	for simple@megatron.ietf.org; Mon, 20 Dec 2004 03:42:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11108
	for <simple@ietf.org>; Mon, 20 Dec 2004 03:42:24 -0500 (EST)
Received: from voyager.coretrek.no ([212.33.142.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJGn-000270-9l
	for simple@ietf.org; Mon, 20 Dec 2004 03:51:58 -0500
Received: from localhost (localhost [127.0.0.1])
	by voyager.coretrek.no (Postfix) with ESMTP
	id C6353A9583; Mon, 20 Dec 2004 09:41:52 +0100 (CET)
Received: from [192.168.1.67] (unknown [82.196.203.62])
	by voyager.coretrek.no (Postfix) with ESMTP
	id F3058A953C; Mon, 20 Dec 2004 09:41:49 +0100 (CET)
In-Reply-To: <7EB139FB-5077-11D9-B702-000D93B0AE1A@nostrum.com>
References: <40AF3C8B-4590-11D9-A939-000D93B0AE1A@nostrum.com>
	<41BD853E.7070400@ericsson.com>
	<7EB139FB-5077-11D9-B702-000D93B0AE1A@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F5C511C4-5262-11D9-92E9-000D93C60BA0@telio.no>
Content-Transfer-Encoding: 7bit
From: Hisham Khartabil <hisham.khartabil@telio.no>
Subject: Re: [Simple] MSRP: sdp usage compared to BFCP
Date: Mon, 20 Dec 2004 09:41:36 +0100
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.619)
X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Robert Sparks <RjS@xten.com>,
        Simple WG <simple@ietf.org>,
        Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
        Rohan Mahy <rohan@ekabal.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit


On Dec 17, 2004, at 11:03 PM, Ben Campbell wrote:

>
> On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:
>
>>
>>> 1) BFCP depends on COMEDIA. MSRP does not.
>>> The reason MSRP does not invoke COMEDIA is mainly a historic one. At 
>>> the time we wrote that part of the spec, COMEDIA had not progressed 
>>> as far as it has now. Instead, MSRP states a default connection 
>>> "direction", and says that other mechanisms can be used to determine 
>>> direction once they become standardized.
>>
>> The thing is that, most likely, comedia will be ready before both 
>> BFCP and MSRP. So, arguing that comedia will not be ready is not a 
>> valid argument anymore.
>>
>> Comedia defines two SDP attributes (setup and connection) that are 
>> used to figure out which end initiates the TCP connection and, on 
>> reception of a new offer, whether the TCP connection needs to be 
>> re-established or the existing TCP connection is OK.
>>
>> I do not think that using these attributes would add too much 
>> complexity to the protocol and having a way to know whether or not an 
>> offer implies that the TCP connection needs to be re-established but 
>> the rest of the parameters should not change seems like important 
>> funcionality. So, even if you want to avoid using the setup attribute 
>> (for some reason) by defining a default connection initiator, I 
>> believe you may still want to use the connection attribute.
>>
>
> Technically, I agree that using comedia is a good idea. My concern now 
> is simply that every new thing we add is that much more delay in 
> completing MSRP. I don't think think it is trivial to add it, as the 
> presence of relays complicates things.  I see two possible ways to 
> move forward with this:
>
> 1) Leave MSRP as is, and follow up shortly with a draft on how to use 
> COMEDIA with MSRP. I think this could be done in a backwards 
> compatible way, by saying that if the COMEDIA attributes are not 
> present, it falls back to the default behavior.

What is the benefit of adding comedia later? Its either now or never, 
IMO.
>
> 2) Go ahead and add COMEDIA support to the base spec, with a small but 
> non-trivial delay while we make sure we don't break something.

What is the benefit of using comedia instead of what we have now in the 
draft? If nothing, then I vote for the third option: leave it as it is.

Regards,
Hisham

>
> Thoughts? (encouraged from anyone, but _particularly_ from the 
> chairs...)
>
> Ben.
>


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


From simple-bounces@ietf.org  Mon Dec 20 04:12:54 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13029;
	Mon, 20 Dec 2004 04:12:53 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgJkK-0002uf-2j; Mon, 20 Dec 2004 04:22:28 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgJUM-000190-Rn; Mon, 20 Dec 2004 04:05:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgJT8-0000wJ-10; Mon, 20 Dec 2004 04:04:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12596;
	Mon, 20 Dec 2004 04:04:40 -0500 (EST)
Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgJcK-0002jz-MC; Mon, 20 Dec 2004 04:14:14 -0500
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; 
	Mon, 20 Dec 2004 17:56:40 +0900
Received: from spam.etri.re.kr ([129.254.16.120]) by email1.etri.info with
	Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Dec 2004 16:58:13 +0900
Received: (snipe 19432 invoked by alias); 20 Dec 2004 16:51:53 +0900
Received: from geopriv-bounces@ietf.org with Spamsniper 2.83.27 (Processed in
	0.756722 secs); 
Received: from unknown (HELO megatron.ietf.org) (132.151.6.71)
	by unknown with SMTP; 20 Dec 2004 16:51:52 +0900
X-RCPTTO: cbh@etri.re.kr
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgIMA-0000uH-P9; Mon, 20 Dec 2004 02:53:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgIIw-0000Bb-Hk; Mon, 20 Dec 2004 02:50:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08228;
	Mon, 20 Dec 2004 02:50:05 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgIS8-0000xp-Tb; Mon, 20 Dec 2004 02:59:38 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2004 23:54:31 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBK7nSdP014918;
	Sun, 19 Dec 2004 23:49:28 -0800 (PST)
Received: from [192.168.1.101] (che-vpn-cluster-2-23.cisco.com [10.86.242.23])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGL19154;
	Sun, 19 Dec 2004 23:49:29 -0800 (PST)
Message-ID: <41C68408.4030707@cisco.com>
Date: Mon, 20 Dec 2004 02:49:28 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Geopriv] Re: [Simple] Usage
	of	substitution	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>	<41C02A85.3050608@nokia.com>
	<41C056C8.5070400@cisco.com>	<41C0AC71.3060001@cs.columbia.edu>
	<41C2B529.40807@nokia.com>
In-Reply-To: <41C2B529.40807@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
X-OriginalArrivalTime: 20 Dec 2004 07:58:13.0560 (UTC)
	FILETIME=[A7DF4B80:01C4E669]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
        Simple WG <simple@ietf.org>,
        ext Henning Schulzrinne <hgs@cs.columbia.edu>
X-BeenThere: simple@ietf.org
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit


inline.

Jari Urpalainen wrote:

> ext Henning Schulzrinne wrote:
> 
>> As an additional datapoint:
>>
>> http://www.w3.org/TR/xmlschema-0/
>>
>> says (Section 5.5):
>>
>> "The lax  value of the processContents  attribute instructs an XML 
>> processor to validate the element content on a can-do basis: It will 
>> validate elements and attributes for which it can obtain schema 
>> information, but it will not signal errors for those it cannot obtain 
>> any schema information."
>>
>> That seems roughly what we want, with the exception of not being able 
>> to constrain the positioning of elements noted below.
>>
> If there's only a single extension point then also this positioning 
> problem vanishes. However, I still have a problem understanding 
> (regarding common-policy) "what we want" as I can't see any problem with 
> the current draft besides perhaps the usefulness of Content-Type 
> registration which is imo needed in presence-rules instead.

The problem case I am worried about is the following.

We are using xcap. A client is managing its presence authorization 
policies. It attempts to upload a document to the server. The client is 
made from a different vendor from the server, and has recently been 
upgraded to support a new permission type. This new permission is not 
understood by the server.

As currently defined, since xcap servers have to do xml validation, the 
user will not be able to upload its permissions. I believe it should be 
able to do so. We have designed the common-policy work to be "privacy 
safe" so even if permissions unknown to the server are included, 
additional information can never be leaked.

-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

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

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


From simple-bounces@ietf.org  Mon Dec 20 04:15:29 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13370;
	Mon, 20 Dec 2004 04:15:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgJmQ-00030h-Em; Mon, 20 Dec 2004 04:25:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgJc4-00025g-Cz; Mon, 20 Dec 2004 04:13:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJba-0001tu-Ke
	for simple@megatron.ietf.org; Mon, 20 Dec 2004 04:13:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13077
	for <simple@ietf.org>; Mon, 20 Dec 2004 04:13:24 -0500 (EST)
Received: from comversegw.icomverse.com ([192.118.48.248]
	helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJkl-0002ut-9c
	for simple@ietf.org; Mon, 20 Dec 2004 04:22:59 -0500
Received: from il-tlv-bridge02.comverse.com (il-tlv-bridge02.comverse.com
	[10.115.242.50])
	by il-tlv-smtpout1.icomverse.com (8.13.1/8.13.1) with ESMTP id
	iBK94fR8010117 for <simple@ietf.org>; Mon, 20 Dec 2004 11:04:50 +0200
Received: from il-tlv-mail02.comverse.com ([10.115.242.26]) by
	il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 20 Dec 2004 11:13:08 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 20 Dec 2004 11:12:29 +0200
Message-ID: <522B9797154BD549B17BA4EAF1DF200C1082F1@il-tlv-mail02.comverse.com>
Thread-Topic: Code Generators
Thread-Index: AcTmdAe8TIlR1anhQYCEbx4WUlBT9w==
From: "Nevo Oded" <Oded.Nevo@comverse.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 20 Dec 2004 09:13:08.0747 (UTC)
	FILETIME=[1F3665B0:01C4E674]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Subject: [Simple] Code Generators
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="===============1332311792=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8

This is a multi-part message in MIME format.

--===============1332311792==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4E674.07BC97CB"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E674.07BC97CB
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi=20
Does anyone know any c++ code generators which=20
implement the following:
1. Generates objects according to XML schema.
2. Generate parse code according to XML schema.
I believe that code generators according to XML schemas
Can contribute to SIMPLE interoperability. =20
10x Oded

------_=_NextPart_001_01C4E674.07BC97CB
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6980.59">
<TITLE>Code Generators</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Hi =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Does =
anyone know any c++ code generators which </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">implement the following:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">1. =
Generates objects according to XML schema.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">2. =
Generate parse code according to XML schema.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">I =
believe that code generators according to XML schemas</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Can =
contribute to SIMPLE interoperability.&nbsp; </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">10x =
Oded</FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E674.07BC97CB--


--===============1332311792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1332311792==--



From simple-bounces@ietf.org  Mon Dec 20 12:26:13 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17457;
	Mon, 20 Dec 2004 12:26:13 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgRRo-0006Wc-JZ; Mon, 20 Dec 2004 12:35:52 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgR9U-0004Bo-UK; Mon, 20 Dec 2004 12:16:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgR1k-0001EC-2C; Mon, 20 Dec 2004 12:08:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16325;
	Mon, 20 Dec 2004 12:08:53 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgRB1-00067G-5L; Mon, 20 Dec 2004 12:18:32 -0500
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBKH8Rc27693; Mon, 20 Dec 2004 19:08:36 +0200 (EET)
X-Scanned: Mon, 20 Dec 2004 19:13:15 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iBKHDF68018964;
	Mon, 20 Dec 2004 19:13:15 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00WZbBM9; Mon, 20 Dec 2004 19:13:13 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBKH7L315376; Mon, 20 Dec 2004 19:07:21 +0200 (EET)
Received: from kusti.research.nokia.com ([172.21.56.13]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Mon, 20 Dec 2004 19:07:19 +0200
Received: from [172.21.50.105] (xitami.research.nokia.com [172.21.50.105])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id E80CF93B77; Mon, 20 Dec 2004 19:07:19 +0200 (EET)
Message-ID: <41C705E2.1020600@nokia.com>
Date: Mon, 20 Dec 2004 19:03:30 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Geopriv] Re: [Simple]
	Usage	of	substitution	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>	<41C02A85.3050608@nokia.com>	<41C056C8.5070400@cisco.com>	<41C0AC71.3060001@cs.columbia.edu>	<41C2B529.40807@nokia.com>
	<41C68408.4030707@cisco.com>
In-Reply-To: <41C68408.4030707@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Dec 2004 17:07:20.0000 (UTC)
	FILETIME=[5D7B1400:01C4E6B6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
        Simple WG <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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit

ext Jonathan Rosenberg wrote:

>
> inline.
>
> Jari Urpalainen wrote:
>
>> ext Henning Schulzrinne wrote:
>>
>>> As an additional datapoint:
>>>
>>> http://www.w3.org/TR/xmlschema-0/
>>>
>>> says (Section 5.5):
>>>
>>> "The lax  value of the processContents  attribute instructs an XML 
>>> processor to validate the element content on a can-do basis: It will 
>>> validate elements and attributes for which it can obtain schema 
>>> information, but it will not signal errors for those it cannot 
>>> obtain any schema information."
>>>
>>> That seems roughly what we want, with the exception of not being 
>>> able to constrain the positioning of elements noted below.
>>>
>> If there's only a single extension point then also this positioning 
>> problem vanishes. However, I still have a problem understanding 
>> (regarding common-policy) "what we want" as I can't see any problem 
>> with the current draft besides perhaps the usefulness of Content-Type 
>> registration which is imo needed in presence-rules instead.
>
>
> The problem case I am worried about is the following.
>
> We are using xcap. A client is managing its presence authorization 
> policies. It attempts to upload a document to the server. The client 
> is made from a different vendor from the server, and has recently been 
> upgraded to support a new permission type. This new permission is not 
> understood by the server.
>
> As currently defined, since xcap servers have to do xml validation, 
> the user will not be able to upload its permissions. I believe it 
> should be able to do so. We have designed the common-policy work to be 
> "privacy safe" so even if permissions unknown to the server are 
> included, additional information can never be leaked.
>
> -Jonathan R.

Thanks Jonathan for the clarification. Although I'll agree with these 
"privacy safe" issues I would still prefer the current very 
deterministic model, because imo dropping the rules that the server 
doesn't understand is exactly the right thing to do as we are expecting 
the server to do the "real" work. Furthermore, as the client already 
knows that it's using an extension  it should be able to fall back to 
the basic rules easily. So I'd rather keep the strict rules.

br,
Jari

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


From simple-bounces@ietf.org  Mon Dec 20 13:50:07 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22235;
	Mon, 20 Dec 2004 13:50:07 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgSl0-0008OR-8v; Mon, 20 Dec 2004 13:59:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgSZg-0005pd-N8; Mon, 20 Dec 2004 13:48:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgSVh-0005TN-Sr; Mon, 20 Dec 2004 13:43:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21973;
	Mon, 20 Dec 2004 13:43:56 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgSex-0008HB-Hj; Mon, 20 Dec 2004 13:53:35 -0500
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-4.cisco.com with ESMTP; 20 Dec 2004 10:43:49 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iBKIhKiv020296;
	Mon, 20 Dec 2004 10:43:20 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-1-176.cisco.com
	[10.86.240.176]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGL42279; Mon, 20 Dec 2004 10:43:17 -0800 (PST)
Message-ID: <41C71D45.7040607@cisco.com>
Date: Mon, 20 Dec 2004 13:43:17 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Geopriv] Re: [Simple]
	Usage	of	substitution	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>	<41C02A85.3050608@nokia.com>	<41C056C8.5070400@cisco.com>	<41C0AC71.3060001@cs.columbia.edu>	<41C2B529.40807@nokia.com>
	<41C68408.4030707@cisco.com> <41C705E2.1020600@nokia.com>
In-Reply-To: <41C705E2.1020600@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
        Simple WG <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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit



Jari Urpalainen wrote:


>>
>> The problem case I am worried about is the following.
>>
>> We are using xcap. A client is managing its presence authorization 
>> policies. It attempts to upload a document to the server. The client 
>> is made from a different vendor from the server, and has recently been 
>> upgraded to support a new permission type. This new permission is not 
>> understood by the server.
>>
>> As currently defined, since xcap servers have to do xml validation, 
>> the user will not be able to upload its permissions. I believe it 
>> should be able to do so. We have designed the common-policy work to be 
>> "privacy safe" so even if permissions unknown to the server are 
>> included, additional information can never be leaked.
>>
>> -Jonathan R.
> 
> 
> Thanks Jonathan for the clarification. Although I'll agree with these 
> "privacy safe" issues I would still prefer the current very 
> deterministic model, because imo dropping the rules that the server 
> doesn't understand is exactly the right thing to do as we are expecting 
> the server to do the "real" work. Furthermore, as the client already 
> knows that it's using an extension  it should be able to fall back to 
> the basic rules easily. So I'd rather keep the strict rules.

I don't follow you here.

With common-policy as currently defined, the server won't just "drop the 
rules it doesn't understand" - the entire document will fail validation, 
and no rules will be placed on the server at all.

Perhaps what you are proposing is that the request should fail, and that 
the client should have a way to figure out why, and then adjust its 
document to only use namespaces understood by the server?

-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 Dec 20 14:56:04 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27985;
	Mon, 20 Dec 2004 14:56:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgTmq-0001Ys-69; Mon, 20 Dec 2004 15:05:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgTYl-0006R8-9V; Mon, 20 Dec 2004 14:51:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgTX2-00068b-Kg; Mon, 20 Dec 2004 14:49:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27651;
	Mon, 20 Dec 2004 14:49:22 -0500 (EST)
Received: from voyager.coretrek.no ([212.33.142.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgTgL-0001PM-Uc; Mon, 20 Dec 2004 14:59:02 -0500
Received: from localhost (localhost [127.0.0.1])
	by voyager.coretrek.no (Postfix) with ESMTP
	id 81AEBA959F; Mon, 20 Dec 2004 20:48:52 +0100 (CET)
Received: from [192.168.1.67] (unknown [82.196.203.62])
	by voyager.coretrek.no (Postfix) with ESMTP
	id 0507FA9586; Mon, 20 Dec 2004 20:48:50 +0100 (CET)
In-Reply-To: <41C71D45.7040607@cisco.com>
References: <41BE743B.8040003@cisco.com>	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>	<41C02A85.3050608@nokia.com>	<41C056C8.5070400@cisco.com>	<41C0AC71.3060001@cs.columbia.edu>	<41C2B529.40807@nokia.com>
	<41C68408.4030707@cisco.com> <41C705E2.1020600@nokia.com>
	<41C71D45.7040607@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2A48A1C8-52C0-11D9-BBE5-000D93C60BA0@telio.no>
Content-Transfer-Encoding: 7bit
From: Hisham Khartabil <hisham.khartabil@telio.no>
Subject: Re: [Geopriv] Re: [Simple]
	Usage	of	substitution	groups	in	draft-ietf-geopriv-common-policy
Date: Mon, 20 Dec 2004 20:48:48 +0100
To: Jonathan Rosenberg <jdrosen@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>,
        Jari Urpalainen <jari.urpalainen@nokia.com>,
        Paul Kyzivat <pkyzivat@cisco.com>, Simple WG <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
X-Spam-Score: 0.5 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit


On Dec 20, 2004, at 7:43 PM, Jonathan Rosenberg wrote:

>
>
> Jari Urpalainen wrote:
>
>
>>>
>>> The problem case I am worried about is the following.
>>>
>>> We are using xcap. A client is managing its presence authorization 
>>> policies. It attempts to upload a document to the server. The client 
>>> is made from a different vendor from the server, and has recently 
>>> been upgraded to support a new permission type. This new permission 
>>> is not understood by the server.
>>>
>>> As currently defined, since xcap servers have to do xml validation, 
>>> the user will not be able to upload its permissions. I believe it 
>>> should be able to do so. We have designed the common-policy work to 
>>> be "privacy safe" so even if permissions unknown to the server are 
>>> included, additional information can never be leaked.
>>>
>>> -Jonathan R.
>> Thanks Jonathan for the clarification. Although I'll agree with these 
>> "privacy safe" issues I would still prefer the current very 
>> deterministic model, because imo dropping the rules that the server 
>> doesn't understand is exactly the right thing to do as we are 
>> expecting the server to do the "real" work. Furthermore, as the 
>> client already knows that it's using an extension  it should be able 
>> to fall back to the basic rules easily. So I'd rather keep the strict 
>> rules.
>
> I don't follow you here.
>
> With common-policy as currently defined, the server won't just "drop 
> the rules it doesn't understand" - the entire document will fail 
> validation, and no rules will be placed on the server at all.
>
> Perhaps what you are proposing is that the request should fail, and 
> that the client should have a way to figure out why, and then adjust 
> its document to only use namespaces understood by the server?

Why wait until it fails? As I said in an earlier email, the client can 
query for server capabilities if it REQUIRES that server to support a 
certain extension. If the client doesnt care, then it just uses the 
extensions. The client doesnt care in cases where the server need not 
know the semantics of things.

Regards,
Hisham

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


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


From simple-bounces@ietf.org  Mon Dec 20 22:23:00 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10369;
	Mon, 20 Dec 2004 22:23:00 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgalQ-0006M6-1R; Mon, 20 Dec 2004 22:32:45 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgaaV-0005y7-G8; Mon, 20 Dec 2004 22:21:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgaZP-0005lz-V8
	for simple@megatron.ietf.org; Mon, 20 Dec 2004 22:20:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10124
	for <simple@ietf.org>; Mon, 20 Dec 2004 22:20:17 -0500 (EST)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgaim-0006Io-RH
	for simple@ietf.org; Mon, 20 Dec 2004 22:30:02 -0500
Received: from razor.cs.columbia.edu
	(IDENT:w4mlTJ9X2xnhBx46QAtaMb40PtlMO5dR@razor.cs.columbia.edu
	[128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBL3KEe9012011
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); 
	Mon, 20 Dec 2004 22:20:15 -0500 (EST)
Received: from [127.0.0.1] (IDENT:d/zoSCKUb8QHIKiUBogZoLdoFLwKwewY@localhost
	[127.0.0.1])
	by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBL3KDU3013200;
	Mon, 20 Dec 2004 22:20:13 -0500
Message-ID: <41C79672.4050901@cs.columbia.edu>
Date: Mon, 20 Dec 2004 22:20:18 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aki Niemi <aki.niemi@nokia.com>
Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for
	moving forward
References: <41B60EAD.5090504@cisco.com> <41C2997D.9010800@nokia.com>
In-Reply-To: <41C2997D.9010800@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0,
	Antispam-Data: 2004.12.20.46
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0,
	__SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Content-Transfer-Encoding: 7bit

Aki Niemi wrote:

> I don't think making the dispatcher visible to the composer/watcher 
> actually solves the real problem; it does however reaffirm the statement 
> made in the data model that unique contacts URIs are required in service 
> tuples. The primary motivation for this requirement seems to be that it 
> enables overriding service elements.



> 
> I think we are working with the wrong publication model to begin with, 
> which makes override of service elements problematic. The publication 
> model is that of a presentity employing a set of PUAs with equal rights 
> -- no one PUA is more authoritative than another. They are all 
> publishing their own full view of the presentity's service statuses.

Actually, there does seem to be a hierarchy, namely that "latest is 
best", or "most frequent publisher wins".

> So I think ultimately, we need a new interface to the composer, call it 
> root account, that gives us a way to "kill" publications that are 
> publishing stale event state. Perhaps such an interface could be 
> provided as part of the composer policy or authorization policy, but I 
> don't think it necessarily requires uniqueness of service URIs.

I wouldn't think it requires uniqueness. If you can explicitly yank a 
tuple, you can much more easily, without worrying about URL matching, 
yank it by its tuple id handle.

I like the 'root' analogy, although I see this more like a filter: An 
entity representing the presentity (logically similar to the one that 
publishes rules, for example) would add a filtering policy. Indeed, in 
many ways it would probably look similar to the current rules, except 
without reference to a specific receiver. This could be as simple as two 
sets of XPath expressions that stipulate the tuples to include and those 
to remove. For those purposes, you probably want a source identifier or 
a tuple identifier, not something that is subject to change with every 
reboot of the PUA, like a GRUU.

We already assume that we have a central rulemaker that issues 
non-contradictory privacy rules. This same logical entity would then 
provide the the composition policy rules. (The data model hints at that, 
but doesn't say much about the identity of the rulemaker.)



> 
> If we reverse the assumption made in the data model that requires 
> uniqueness of service URIs, will watchers generally be confused if they 
> encounter service tuples with the same contact? I don't think so, as 
> long as the watcher does the following:
> 
> 1) takes note of the meta-information of each service (timestamp, 
> q-value) giving preference to a fresher service, or one with higher 
> q-value.
> 
> 2) takes note of the characteristics of each service (prescaps for 
> example) along with the contact URI, applying its own known 
> characteristics and service URIs to determine what service the tuple is 
> describing
> 
> 3) takes note of the status, meaning that a basic status of OPEN is a 
> better choice than one with CLOSED, for example
> 
> 4) all of the above being equal, folds all identical services together 
> (after all they are identical in all ways that have relevance to the 
> watcher)

Agreed; this is just applying the standard pivoting and merging rules at 
the watcher, with the advantage that only the watcher knows what 
information is meaningful and differentiating to it.

> 
> These steps should guarantee that the watcher can always make a proper 
> selection of which service to invoke. Invoking the service then involves 
> more than a simple "clicking the contact", since in the case of SIP the 
> watcher generally will e.g. construct an SDP offer that matches the 
> service that the watcher thinks the tuple is describing. I believe the 
> invoking of a service MUST work using an AoR. If an INVITE offering 
> voice ends up served by a chess application, I think the system is 
> utterly broken, and needs to be fixed. One fix could be using GRUUs as 
> contacts, but that is not the only fix, and may not even be the best 
> one, IMHO.
> 
> All and all, I still don't buy the requirement for unique service URIs. 
> Also, I think that the default composer policy of union (i.e., collect 
> all service tuples together intact) will take care of the 95% need, 
> leaving out more sophisticated things like override and 
> merging/splitting for future study. These more sophisticated needs can 
> be tackled later, when more real-world experience has been accumulated 
> about them. I don't think we currently are able to see exactly what the 
> needs of this 5% are, so the best way forward is to take the 95%, make 
> it as flexible as possible to accommodate this future work and run with it.
> 


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


From simple-bounces@ietf.org  Tue Dec 21 05:05:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22031;
	Tue, 21 Dec 2004 05:05:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cgh3Q-0007TW-76; Tue, 21 Dec 2004 05:15:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cggqt-0007v6-HV; Tue, 21 Dec 2004 05:02:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CggmE-0007Ko-8W; Tue, 21 Dec 2004 04:57:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21385;
	Tue, 21 Dec 2004 04:57:56 -0500 (EST)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cggvf-0007Kh-FO; Tue, 21 Dec 2004 05:07:43 -0500
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBL9vLc17801; Tue, 21 Dec 2004 11:57:23 +0200 (EET)
X-Scanned: Tue, 21 Dec 2004 11:56:39 +0200 Nokia Message Protector V1.3.31
	2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iBL9udso022646;
	Tue, 21 Dec 2004 11:56:39 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks003.ntc.nokia.com 00L3daE3; Tue, 21 Dec 2004 11:56:37 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	iBL9ua311306; Tue, 21 Dec 2004 11:56:36 +0200 (EET)
Received: from kusti.research.nokia.com ([172.21.56.13]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 21 Dec 2004 11:55:51 +0200
Received: from [172.21.50.105] (xitami.research.nokia.com [172.21.50.105])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id E105A93B6A; Tue, 21 Dec 2004 11:55:50 +0200 (EET)
Message-ID: <41C7F240.7070608@nokia.com>
Date: Tue, 21 Dec 2004 11:52:00 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Hisham Khartabil <hisham.khartabil@telio.no>
Subject: Re: [Geopriv] Re: [Simple]
	Usage	of	substitution	groups	in	draft-ietf-geopriv-common-policy
References: <41BE743B.8040003@cisco.com>	<41BE8ED0.9090303@nokia.com>	<41BF0186.3050507@cisco.com>	<41C02A85.3050608@nokia.com>	<41C056C8.5070400@cisco.com>	<41C0AC71.3060001@cs.columbia.edu>	<41C2B529.40807@nokia.com>
	<41C68408.4030707@cisco.com> <41C705E2.1020600@nokia.com>
	<41C71D45.7040607@cisco.com>
	<2A48A1C8-52C0-11D9-BBE5-000D93C60BA0@telio.no>
In-Reply-To: <2A48A1C8-52C0-11D9-BBE5-000D93C60BA0@telio.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Dec 2004 09:55:51.0067 (UTC)
	FILETIME=[40E326B0:01C4E743]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
        Simple WG <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
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit

ext Hisham Khartabil wrote:

>
> On Dec 20, 2004, at 7:43 PM, Jonathan Rosenberg wrote:
>
>>
>>
>> Jari Urpalainen wrote:
>>
>>
>>>>
>>>> The problem case I am worried about is the following.
>>>>
>>>> We are using xcap. A client is managing its presence authorization 
>>>> policies. It attempts to upload a document to the server. The 
>>>> client is made from a different vendor from the server, and has 
>>>> recently been upgraded to support a new permission type. This new 
>>>> permission is not understood by the server.
>>>>
>>>> As currently defined, since xcap servers have to do xml validation, 
>>>> the user will not be able to upload its permissions. I believe it 
>>>> should be able to do so. We have designed the common-policy work to 
>>>> be "privacy safe" so even if permissions unknown to the server are 
>>>> included, additional information can never be leaked.
>>>>
>>>> -Jonathan R.
>>>
>>> Thanks Jonathan for the clarification. Although I'll agree with 
>>> these "privacy safe" issues I would still prefer the current very 
>>> deterministic model, because imo dropping the rules that the server 
>>> doesn't understand is exactly the right thing to do as we are 
>>> expecting the server to do the "real" work. Furthermore, as the 
>>> client already knows that it's using an extension  it should be able 
>>> to fall back to the basic rules easily. So I'd rather keep the 
>>> strict rules.
>>
>>
>> I don't follow you here.
>>
>> With common-policy as currently defined, the server won't just "drop 
>> the rules it doesn't understand" - the entire document will fail 
>> validation, and no rules will be placed on the server at all.
>>
>> Perhaps what you are proposing is that the request should fail, and 
>> that the client should have a way to figure out why, and then adjust 
>> its document to only use namespaces understood by the server?
>
yes, this is what I meant (and I certainly hope that extensions play a 
minor role here).

> Why wait until it fails? As I said in an earlier email, the client can 
> query for server capabilities if it REQUIRES that server to support a 
> certain extension. If the client doesnt care, then it just uses the 
> extensions. The client doesnt care in cases where the server need not 
> know the semantics of things.
>
> Regards,
> Hisham

yes you can utilize server capabilities when you'll have a xcap server 
(which may not always be the case). But the use-case here is what is the 
right behavior in this context.

br,
Jari

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


From simple-bounces@ietf.org  Wed Dec 22 04:16:04 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03948;
	Wed, 22 Dec 2004 04:16:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ch2ku-0007JN-Ln; Wed, 22 Dec 2004 04:26:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ch2Sq-0002Aq-O0; Wed, 22 Dec 2004 04:07:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch2Rt-0001vd-2I
	for simple@megatron.ietf.org; Wed, 22 Dec 2004 04:06:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03420
	for <simple@ietf.org>; Wed, 22 Dec 2004 04:06:22 -0500 (EST)
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch2bV-00075P-UH
	for simple@ietf.org; Wed, 22 Dec 2004 04:16:23 -0500
Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se
	[138.85.133.52])
	by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id iBM96rCR007432;
	Wed, 22 Dec 2004 03:06:54 -0600 (CST)
Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service
	(5.5.2657.72) id <ZMK0R2RV>; Wed, 22 Dec 2004 03:05:52 -0600
Message-ID: <1068F9D378B09943A35970BF8F930A7A488164@lmc37.lmc.ericsson.se>
From: "George Foti (QA/EMC)" <george.foti@ericsson.com>
To: "'Aki Niemi'" <aki.niemi@nokia.com>,
        "'ext Jonathan Rosenberg'"
	<jdrosen@cisco.com>
Subject: RE: [Simple] modeling dispatchers in the data model: a proposal f
	or moving forward
Date: Tue, 21 Dec 2004 04:53:27 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-Spam-Score: 0.4 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
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
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Hi Aki,

> So I think ultimately, we need a new interface to the 
> composer, call it 
> root account, that gives us a way to "kill" publications that are 
> publishing stale event state. Perhaps such an interface could be 
> provided as part of the composer policy or authorization 
> policy, but I 
> don't think it necessarily requires uniqueness of service URIs.

Can you make a concrete proposal. Is this an automatic thing or manual thing
What are the triggers to this animal whatever it is, and who can invoke it

> These steps should guarantee that the watcher can always make 
> a proper 
> selection of which service to invoke. Invoking the service 
> then involves 
> more than a simple "clicking the contact", since in the case 
> of SIP the 
> watcher generally will e.g. construct an SDP offer that matches the 
> service that the watcher thinks the tuple is describing. I 
> believe the 
> invoking of a service MUST work using an AoR. If an INVITE offering 
> voice ends up served by a chess application, I think the system is 
> utterly broken, and needs to be fixed. One fix could be using 
> GRUUs as 
> contacts, but that is not the only fix, and may not even be the best 
> one, IMHO.
> 

The only way to click the contact and guarantee to reach the intended service is to either have a distinct service-URI per service ( as suggested in the current model) or use caller/callee preferences, (with require parameter).

Do U agree ? and why can we not have both options.

Rgds/gf

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


From simple-bounces@ietf.org  Wed Dec 22 09:09:18 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24761;
	Wed, 22 Dec 2004 09:09:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ch7Kf-000788-Iw; Wed, 22 Dec 2004 09:19:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ch6xF-0002Rm-IZ; Wed, 22 Dec 2004 08:55:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch6oM-0007EJ-IC
	for simple@megatron.ietf.org; Wed, 22 Dec 2004 08:45:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23370
	for <simple@ietf.org>; Wed, 22 Dec 2004 08:45:52 -0500 (EST)
Received: from tierw.net.avaya.com ([198.152.13.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch6y2-0006YF-Jn
	for simple@ietf.org; Wed, 22 Dec 2004 08:55:55 -0500
Received: from tierw.net.avaya.com (localhost [127.0.0.1])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	iBMDasja019195
	for <simple@ietf.org>; Wed, 22 Dec 2004 08:36:55 -0500 (EST)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com
	[198.152.6.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	iBMDarja019153
	for <simple@ietf.org>; Wed, 22 Dec 2004 08:36:53 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] modeling dispatchers in the data model: a proposal
	formoving forward
Date: Wed, 22 Dec 2004 08:45:49 -0500
Message-ID: <8CA1128D59AD27429985B397118CEDDF047A07B2@nj7460avexu1.global.avaya.com>
Thread-Topic: [Simple] modeling dispatchers in the data model: a proposal
	formoving forward
Thread-Index: AcTnDHfFLX2nB5ZZQaywXeSjIqBxBQBHYy+Q
From: "Boyer, David G \(Dave\)" <dgboyer@avaya.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
        "Aki Niemi" <aki.niemi@nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: quoted-printable


Been thinking about this one a bit and I am not sure we need
something like a dispatcher at all.  If PUAs are publishing
stale data I don't see why the composer should deal with it.
One composer may have rules that don't indicate when a presence
document is stale, another one might. The composer will process
the data it receives without judging it's validity.

some comments inline
>=20
> >=20
> > I think we are working with the wrong publication model to=20
> begin with,=20
> > which makes override of service elements problematic. The=20
> publication=20
> > model is that of a presentity employing a set of PUAs with=20
> equal rights=20
> > -- no one PUA is more authoritative than another. They are all=20
> > publishing their own full view of the presentity's service statuses.
>=20
> Actually, there does seem to be a hierarchy, namely that "latest is=20
> best", or "most frequent publisher wins".

This hierarchy exists for some composers, not all.  Depends entirely
on the rules the composer uses to process the documents.  Latest is best
may be superceeded by a person rule that was invoked that says ignore=20
all future state changes until I make myself available again.  This
should be left to implementers.
>=20
> > So I think ultimately, we need a new interface to the=20
> composer, call it=20
> > root account, that gives us a way to "kill" publications that are=20
> > publishing stale event state. Perhaps such an interface could be=20
> > provided as part of the composer policy or authorization=20
> policy, but I=20
> > don't think it necessarily requires uniqueness of service URIs.

What is an example of a publisher that is publishing stale event
state?
>=20
> I wouldn't think it requires uniqueness. If you can explicitly yank a=20
> tuple, you can much more easily, without worrying about URL matching,=20
> yank it by its tuple id handle.

What if the tuple contains information concerning two services - voice
and
IM, voice is stale IM is not.  Do you yank the tuple even though some
of it is valid?  Probably another local policy decision.
>=20
> I like the 'root' analogy, although I see this more like a filter: An=20
> entity representing the presentity (logically similar to the one that=20
> publishes rules, for example) would add a filtering policy.=20
> Indeed, in=20
> many ways it would probably look similar to the current rules, except=20
> without reference to a specific receiver. This could be as=20
> simple as two=20
> sets of XPath expressions that stipulate the tuples to=20
> include and those=20
> to remove. For those purposes, you probably want a source=20
> identifier or=20
> a tuple identifier, not something that is subject to change=20
> with every=20
> reboot of the PUA, like a GRUU.
>=20
> We already assume that we have a central rulemaker that issues=20
> non-contradictory privacy rules. This same logical entity would then=20
> provide the the composition policy rules. (The data model=20
> hints at that,=20
> but doesn't say much about the identity of the rulemaker.)
>=20
Minor nit - the "central" rulemaker can be distributed - filtering
separated
from composition - different vendors may provide these capabilities.
Dave

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


From simple-bounces@ietf.org  Wed Dec 22 11:15:38 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07639;
	Wed, 22 Dec 2004 11:15:38 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ch9J0-00033J-9d; Wed, 22 Dec 2004 11:25:43 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ch8xJ-0007RL-UD; Wed, 22 Dec 2004 11:03:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch8ta-0005ln-Kd
	for simple@megatron.ietf.org; Wed, 22 Dec 2004 10:59:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06736
	for <simple@ietf.org>; Wed, 22 Dec 2004 10:59:23 -0500 (EST)
Received: from web53908.mail.yahoo.com ([206.190.36.218])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ch93H-0002dC-3u
	for simple@ietf.org; Wed, 22 Dec 2004 11:09:28 -0500
Received: (qmail 13941 invoked by uid 60001); 22 Dec 2004 15:58:54 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	b=tCP0TGBXa2HO7RBFdNCrUII4bC5Bmv7h8QXtPEMS+SOC/sl7SxvOk7aMfyjfyvBEZ5tGkKtPo+2szFcE5pQUI1jjVIVuaHCwIXXatHQC0AsUdpuOHBMYpQGBbxvx03QNEXZtqZZzGTVwepYwDowrkAQMhQkXpz/t1dSxBLFatyY=
	; 
Message-ID: <20041222155854.13939.qmail@web53908.mail.yahoo.com>
Received: from [203.126.136.223] by web53908.mail.yahoo.com via HTTP;
	Wed, 22 Dec 2004 07:58:53 PST
Date: Wed, 22 Dec 2004 07:58:53 -0800 (PST)
From: Kamalakanta Palei <kkpalei@yahoo.com>
To: simple@ietf.org, Jonathan Rosenberg <jdrosen@cisco.com>
In-Reply-To: <41C71D45.7040607@cisco.com>
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Subject: [Simple] IM delivery
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="===============1851078632=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

--===============1851078632==
Content-Type: multipart/alternative; boundary="0-1196356120-1103731133=:10471"

--0-1196356120-1103731133=:10471
Content-Type: text/plain; charset=us-ascii


Hi

Suppose user A has logged in two different sip devices (that support presence and IM).

When a different user B sends an IM to A (say through proxy), then that IM will be delivered to which device.

Will this IM be delivered to any arbitrary device or any specific rule is there.

Any comment, highly appriciated.

Regards

Kamal


		
---------------------------------
Do you Yahoo!?
 Dress up your holiday email, Hollywood style. Learn more.
--0-1196356120-1103731133=:10471
Content-Type: text/html; charset=us-ascii

<DIV>
<P>Hi</P>
<P>Suppose user A has logged in two different sip devices (that support presence and IM).</P>
<P>When a different user B sends an IM to A (say through proxy), then that IM will be delivered to which device.</P>
<P>Will this IM be delivered to any arbitrary device or any specific rule is there.</P>
<P>Any comment, highly appriciated.</P>
<P>Regards</P>
<P>Kamal</P></DIV><p>
		<hr size=1>Do you Yahoo!?<br> 
Dress up your holiday email, Hollywood style. <a href="http://us.rd.yahoo.com/evt=29909/*http://celebrity.mail.yahoo.com">Learn more.</a>
--0-1196356120-1103731133=:10471--


--===============1851078632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1851078632==--



From simple-bounces@ietf.org  Wed Dec 22 11:56:08 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12452;
	Wed, 22 Dec 2004 11:56:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ch9wC-0004NU-4N; Wed, 22 Dec 2004 12:06:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ch9i6-0000Gs-1R; Wed, 22 Dec 2004 11:51:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch9Xr-0003oW-65
	for simple@megatron.ietf.org; Wed, 22 Dec 2004 11:41:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10991
	for <simple@ietf.org>; Wed, 22 Dec 2004 11:41:00 -0500 (EST)
Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248]
	helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9hX-0003py-Ls
	for simple@ietf.org; Wed, 22 Dec 2004 11:51:05 -0500
Received: from il-tlv-bridge02.comverse.com (il-tlv-bridge02.comverse.com
	[10.115.242.50])
	by il-tlv-smtpout1.icomverse.com (8.13.1/8.11.6) with ESMTP id
	iBMGVqxY009399 for <simple@ietf.org>; Wed, 22 Dec 2004 18:31:52 +0200
Received: from il-tlv-mail02.comverse.com ([10.115.242.26]) by
	il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 22 Dec 2004 18:40:58 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 22 Dec 2004 18:40:58 +0200
Message-ID: <522B9797154BD549B17BA4EAF1DF200C1082F9@il-tlv-mail02.comverse.com>
Thread-Topic: Presence Data Model : Device - Service Realations
Thread-Index: AcToRQOYYPUwZ3gIT0qiSI5Djzr/sg==
From: "Nevo Oded" <Oded.Nevo@comverse.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 22 Dec 2004 16:40:58.0618 (UTC)
	FILETIME=[03BAD5A0:01C4E845]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Subject: [Simple] Presence Data Model : Device - Service Realations
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="===============0293945969=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0

This is a multi-part message in MIME format.

--===============0293945969==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4E845.03855E31"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E845.03855E31
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi
The draft-ietf-simple-presence-data-model-01 define many to many
Realation between the presentity services to the presentity devices.
A service can be related to list of devices as defined in the service =
schema.
My questions are:
Does the presence status of a service which have a list of devices is =
synchronize
In all the devices the service is execute on?
When one of the devices in the service list is shut down ( when all =
other devices are on)
how does it should reflect on the service presence status?
Does the device list of a service is just a list of all the presentity
Devices that the service installed on, and the presence status =
represents=20
Only the status of the communication mean that could be reached through=20
The uri in the contact attribute?

10x Oded =20

------_=_NextPart_001_01C4E845.03855E31
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6980.59">
<TITLE>Presence Data Model : Device - Service Realations</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Hi</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">The =
draft-ietf-simple-presence-data-model-01 define many to =
many</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Realation between the presentity services to the =
presentity devices.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">A =
service can be related to list of devices as defined in the service =
schema.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">My =
questions are:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Does the =
presence status of a service which have a list of devices is =
synchronize</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">In all =
the devices the service is execute on?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">When one =
of the devices in the service list is shut down ( when all other devices =
are on)</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">how does =
it should reflect on the service presence status?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Does the =
device list of a service is just a list of all the =
presentity</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Devices =
that the service installed on, and the presence status represents =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Only the =
status of the communication mean that could be reached through =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">The uri =
in the contact attribute?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">10x =
Oded&nbsp; </FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E845.03855E31--


--===============0293945969==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0293945969==--



From simple-bounces@ietf.org  Wed Dec 22 14:12:59 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24311;
	Wed, 22 Dec 2004 14:12:59 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChC4e-0008MG-B6; Wed, 22 Dec 2004 14:23:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChBtE-0001do-AC; Wed, 22 Dec 2004 14:11:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ChBnL-0007u8-Si
	for simple@megatron.ietf.org; Wed, 22 Dec 2004 14:05:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23813
	for <simple@ietf.org>; Wed, 22 Dec 2004 14:05:10 -0500 (EST)
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.33)
	id 1ChBx3-00087w-Te
	for simple@ietf.org; Wed, 22 Dec 2004 14:15:15 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-1.cisco.com with ESMTP; 22 Dec 2004 11:11:46 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBMJ4Wo9016166;
	Wed, 22 Dec 2004 11:04:32 -0800 (PST)
Received: from cisco.com (che-vpn-cluster-2-60.cisco.com [10.86.242.60])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANX24347;
	Wed, 22 Dec 2004 14:04:33 -0500 (EST)
Message-ID: <41C9C541.5080601@cisco.com>
Date: Wed, 22 Dec 2004 14:04:33 -0500
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: Kamalakanta Palei <kkpalei@yahoo.com>
Subject: Re: [Simple] IM delivery
References: <20041222155854.13939.qmail@web53908.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Content-Transfer-Encoding: 7bit

Kamal,

Currently there is no simple answer to your question. But the following 
are some possible answers:

1) if you mean an IM using MESSAGE, then it will likely be forked to 
both devices.

1a) If parallel forking is used, then the message will probably be 
displayed on both devices. One of the responses will be returned to the 
sender, and the other will be suppressed by the forking proxy.

1b) If serial forking is used, then if the first accepts it, it will 
only go there.

2) if session mode IM is used via MSRP. Then there is an open issue of 
whether this will be treated like voice, where the callee is alerted and 
must answer before media is delivered, or if IM calls are implicitly 
answered, or if an "early media" session is established and the first 
message sent then.

2a) If treated like a voice call,

2a1) if parallel forking is used, then both devices will be alerted. The 
call will complete to the first one to answer, and the message will be 
delivered there. The other fork will be cancelled.

2a2) If treated like a voice call and serial forking is used, if the 
first device answers then the message will be delivered there. If the 
first device doesn't answer, the other will be tried and if it answers 
the message will go there. Except for timing, 2a1 and 2a2 are the same.

2b) If IM calls are implicitly answered,

2b1) if parallel forking is used then both devices will receive the call 
and both will answer. The first answer to reach the proxy will win, and 
the other will be cancelled. Then the message will be delivered to the 
winner. If the cancel doesn't reach the losing device in time, then both 
200s will go to the caller, which may keep one and terminate the other, 
or may keep them both. This is pretty ugly.

2c) If IM calls result in early media sessions,

2c1) If parallel forking is used, the call will go to both devices, and 
a separate early media session will be established to each. The sender 
will then send the message to both. This message will then be displayed 
on both devices. A user at one of the devices will acknowledge the 
message - possibly by just clicking, or maybe by sending a response. The 
UA can use that as indication to accept the call. When this happens, the 
proxy will cancel the other fork. The other device will then need to 
indicate that it "missed the call". The sender will then continue the 
conversation with the winning device.

2c2) if serial forking used, the call will go to one device, an early 
media session will be established, the message will be sent and 
displayed. If the user acknowledges, the call will complete to it. If 
not, the call will eventually time out and be cancelled. The device will 
indicate the missed call. Then the call will be tried to the other 
device, etc.

I find (2c) to be by far the most attractive way to handle this.

	Paul

Kamalakanta Palei wrote:
> Hi
> 
> Suppose user A has logged in two different sip devices (that support 
> presence and IM).
> 
> When a different user B sends an IM to A (say through proxy), then that 
> IM will be delivered to which device.
> 
> Will this IM be delivered to any arbitrary device or any specific rule 
> is there.
> 
> Any comment, highly appriciated.
> 
> Regards
> 
> Kamal
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Dress up your holiday email, Hollywood style. Learn more. 
> <http://us.rd.yahoo.com/evt=29909/*http://celebrity.mail.yahoo.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  Sun Dec 26 14:19:09 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11514;
	Sun, 26 Dec 2004 14:19:09 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cie5e-0001PS-3K; Sun, 26 Dec 2004 14:30:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CidpU-0005QU-Rm; Sun, 26 Dec 2004 14:13:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cidin-0004uP-IW; Sun, 26 Dec 2004 14:06:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10242;
	Sun, 26 Dec 2004 14:06:27 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CidtL-00011x-Sx; Sun, 26 Dec 2004 14:17:24 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 26 Dec 2004 11:12:10 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBQJ5sHn013784;
	Sun, 26 Dec 2004 11:05:54 -0800 (PST)
Received: from [192.168.1.101] (sjc-vpn4-227.cisco.com [10.21.80.227])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVA22183;
	Sun, 26 Dec 2004 11:05:51 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sun, 26 Dec 2004 11:13:08 -0700
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
From: Cullen Jennings <fluffy@cisco.com>
To: Peter Ridler <ridler@softrac.ca>, "'Joerg Ott'" <jo@tzi.uni-bremen.de>,
        "'Colin Perkins'" <csp@csperkins.org>
Message-ID: <BDF44D44.20BBF%fluffy@cisco.com>
In-Reply-To: <BAYC1-PASMTP0386E41DC19DFD4D1AD8D6EDA00@cez.ice>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>, "mmusic@ietf.org" <mmusic@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Content-Transfer-Encoding: 7bit


What will your two SDP parse engines do differently?


On 12/18/04 7:16 AM, "Peter Ridler" <ridler@softrac.ca> wrote:

> 
> I also agree with Colin and Joerg.
> 
> I will also have two SDP parse engines (one for RTP and another for MSRP).
> This will complicate the code.  Computers do not care about ugly formatting
> --- overall performance should be the concern (I think all text formatted
> protocols are a waste of network bandwidth and memory resources -- but I'm
> stuck with them).
> 
> We should follow the standards as best we can.  If the standard does not
> meet your requirements then define/use another.
> 
> Another text based protocol is draft-ietf-sipping-toip-00.txt  This fits the
> SIP/SDP model nicely.
> 
> Peter
>  
> 
>> -----Original Message-----
>> From: simple-bounces@ietf.org
>> [mailto:simple-bounces@ietf.org] On Behalf Of Joerg Ott
>> Sent: Sunday, December 12, 2004 6:58 AM
>> To: Colin Perkins
>> Cc: Simple WG; mmusic@ietf.org
>> Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
>> 
>> I agree with Colin on the ugliness issue of decomposing URLs
>> into c= and m= lines.  But this is the way SDP has worked and
>> works today.
>> 
>> The present discussion we are having here is about changing
>> SDP to for address/URL handling in one particular case.  This
>> does not strike me as something MSRP should be concerned with.
>> 
>> I would like to make one thing clear: we are either using
>> existing tools in another document or we are building new
>> ones.  There is nothing much in between.
>> 
>> Changing c=/m= semantics means changing SDP.  Just because
>> the syntax still looks the same does not mean that it is
>> still the same protocol.
>> Any entity or generic protocol engine used to dealing with
>> SDP m=/c= would no longer do the right thing.
>> 
>> We see this kind of approach quite often -- by far too often
>> -- over the past years (just think the many "uses" of SIP
>> defined elsewhere, usually resulting in something "a little
>> but not entirely unlike" SIP).
>> 
>> What I would like avoid is having special treatment of SDP
>> depending on what the media type is (or other attributes signify).
>> 
>> Therefore, I strongly agree with Colin's conclusion: take SDP
>> as is or leave it altogether and pursue a different path.
>> 
>> Joerg
>> 
>> 
>> Colin Perkins wrote:
>> 
>>> On 10 Dec 2004, at 21:41, Ben Campbell wrote:
>>> 
>>>> I really need to get closure on this, so I'd appreciate people
>>>> agreeing or disagreeing.
>>>> 
>>>> I have had off-list correspondence indicating both
>> positions. In summary:
>>>> 
>>>> In favor of the change, I had a comment to the effect that
>> changing 
>>>> SDP semantics to ignore the C line and the port field on
>> the M line 
>>>> really changes it to something that is no longer SDP, and
>> that such 
>>>> deviations are in general bad for interop.
>>>> 
>>>> In favor of leaving things as currently specified, I had
>> two comments 
>>>> that decomposing URLs into the C and M lines is ugly, and
>> that having 
>>>> a different mechanism to communicate endpoint addresses vs relay
>>>> addresses is really ugly.
>>>> 
>>>> So, do people agree with one or the other position?
>>> 
>>> 
>>> Decomposing the URL into the "c=" and "m=" lines is very ugly.
>>> Unfortunately, that ugliness is required if you want to use
>> SDP. This 
>>> is why the SDPng work was started, to try to move to something less
>>> horrible...
>>> 
>>> Colin
>>> 
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic


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


From simple-bounces@ietf.org  Mon Dec 27 10:53:12 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23616;
	Mon, 27 Dec 2004 10:53:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CixM4-0006En-30; Mon, 27 Dec 2004 11:04:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CixAI-0006mP-Bz; Mon, 27 Dec 2004 10:52:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cix6R-0005eu-3I
	for simple@megatron.ietf.org; Mon, 27 Dec 2004 10:48:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23202
	for <simple@ietf.org>; Mon, 27 Dec 2004 10:48:09 -0500 (EST)
Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248]
	helo=il-tlv-smtpout2.icomverse.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CixHA-000672-1M
	for simple@ietf.org; Mon, 27 Dec 2004 10:59:16 -0500
Received: from il-tlv-bridge02.comverse.com (il-tlv-bridge02.comverse.com
	[10.115.242.50])
	by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id
	iBRFlro17556 for <simple@ietf.org>; Mon, 27 Dec 2004 17:47:53 +0200
Received: from il-tlv-mail02.comverse.com ([10.115.242.26]) by
	il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 27 Dec 2004 17:48:03 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 27 Dec 2004 17:48:03 +0200
Message-ID: <522B9797154BD549B17BA4EAF1DF200C108303@il-tlv-mail02.comverse.com>
Thread-Topic: Tuple ID
Thread-Index: AcTsK3Ml1ZY3H3RmTh+rVCh30tjBqg==
From: "Nevo Oded" <Oded.Nevo@comverse.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 27 Dec 2004 15:48:03.0549 (UTC)
	FILETIME=[734E80D0:01C4EC2B]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Subject: [Simple] Tuple 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>
Content-Type: multipart/mixed; boundary="===============0980094760=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248

This is a multi-part message in MIME format.

--===============0980094760==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4EC2B.731D15E5"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4EC2B.731D15E5
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi
When Presence Server receives PUBLISH
message from client how does the server should
update presence info for a service, does the service
should be uniquley identified by the "tuple id" or
by the "contact" uri?"

10x Oded

------_=_NextPart_001_01C4EC2B.731D15E5
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6980.59">
<TITLE>Tuple ID</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Hi</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">When =
Presence Server receives PUBLISH</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">message =
from client how does the server should</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">update =
presence info for a service, does the service</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">should =
be uniquley identified by the &quot;tuple id&quot; or</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">by the =
&quot;contact&quot; uri?&quot;</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">10x =
Oded</FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4EC2B.731D15E5--


--===============0980094760==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0980094760==--



From simple-bounces@ietf.org  Mon Dec 27 18:11:05 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15932;
	Mon, 27 Dec 2004 18:11:05 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cj4Bt-0006GH-6e; Mon, 27 Dec 2004 18:22:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cj3zB-0000bL-LZ; Mon, 27 Dec 2004 18:09:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cj3wM-0006iK-CQ; Mon, 27 Dec 2004 18:06:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15224;
	Mon, 27 Dec 2004 18:06:12 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cj479-00068D-Gq; Mon, 27 Dec 2004 18:17:24 -0500
Received: from [192.168.0.108] (adsl-209-30-64-8.dsl.rcsntx.swbell.net
	[209.30.64.8]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBRN63OX014214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Dec 2004 17:06:05 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <41D0955B.2080704@nostrum.com>
Date: Mon, 27 Dec 2004 17:06:03 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Hisham Khartabil <hisham.khartabil@telio.no>
Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern
References: <A0199C6C-48A6-11D9-91F3-000D93B0AE1A@nostrum.com>	<3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com>	<6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org>	<41BC325D.4010808@tzi.uni-bremen.de>
	<C7C9823E-4CE6-11D9-8A90-000D93C60BA0@telio.no>
In-Reply-To: <C7C9823E-4CE6-11D9-8A90-000D93C60BA0@telio.no>
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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>, Joerg Ott <jo@tzi.uni-bremen.de>,
        mmusic@ietf.org, Colin Perkins <csp@csperkins.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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit

Hisham Khartabil wrote:

> I have a question to SDP stack implementers that plan to implement 
> MSRP: Does the current way MSRP specifies the use of SDP (ignore the c 
> line address and the m line port and instead use the attribute a=path) 
> cause problems to you and requires you to do some hacking in your SDP 
> stack? If so, is that acceptable or do you prefer for your MSRP 
> implementation to implement two ways of contructing an MSRP URL 
> depending on the what the next hop is?


Having implemented an SDP parser before, I can comfortably assert that 
the design I employed would require no modification at all to 
accommodate the usage proposed in MSRP.

Users of the SDP parser would need to know to look in the a= lines for 
address information -- but this requires no stack changes.

/a

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