From simple-bounces@ietf.org Mon Nov 1 03:35: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 DAA03439; Mon, 1 Nov 2004 03:35:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXtW-0000vP-6S; Mon, 01 Nov 2004 03:50:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COXSB-0002Tb-Om; Mon, 01 Nov 2004 03:22:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COXR8-0002K9-MV for simple@megatron.ietf.org; Mon, 01 Nov 2004 03:21: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 DAA01950 for ; Mon, 1 Nov 2004 03:21:06 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXVG-000071-NB for simple@ietf.org; Mon, 01 Nov 2004 03:25:27 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA189wl06631; Mon, 1 Nov 2004 10:09:58 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 10:09: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 iA189dqS009712; Mon, 1 Nov 2004 10:09:39 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00yaosUx; Mon, 01 Nov 2004 10:09:38 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 iA189cS14048; Mon, 1 Nov 2004 10:09:38 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 09:59:23 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 09:59:20 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] prescaps and priority (Was: I-DACTION:draft-ietf-simple-prescaps-ext-02.txt) Date: Mon, 1 Nov 2004 09:59:16 +0200 Message-ID: Thread-Topic: [Simple] prescaps and priority (Was: I-DACTION:draft-ietf-simple-prescaps-ext-02.txt) Thread-Index: AcS9aP1wvYW+656vSD+mfur8p00geQAHgd2Q To: X-OriginalArrivalTime: 01 Nov 2004 07:59:20.0395 (UTC) FILETIME=[B177C1B0:01C4BFE8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable > Mikko, >=20 > My xml skills are still limited, so I'm not sure what a use=20 > of (2) would=20 > look like, but (1) certainly looks ugly. > Can we just discuss how a usage would look first, and then figure out=20 > how to declare it? >=20 > Odd as it is, it is legal to say something like > priority=3D"#<=3D10,#=3D30, #>=3D40, #45:50" Yes, it is a bit odd.=20 > I see that as a worst case. So I will use that to work with.=20 > I think the=20 > following might at least read nicely: >=20 > > > > > > > > An advantage of the above is that the simple cases really are simple. > What do you think of that? Yes, that doesn't look bad at all. I would still like to add bit more = syntax into it as follows: or This way all priority values would be enclosed inside a single = element.=20 - Mikko > Paul >=20 > mikko.lonnfors@nokia.com wrote: > > Hi, > >=20 > > inline > >=20 > >=20 > >>I also see another issue that I should have caught before,=20 > because it=20 > >>isn't new. And it is as much a problem for RFC3840 as it is a=20 > >>problem here: > >> > >>The issue is how priority is represented. As part of doing 3840,=20 > >>priority was changed from a set of tokens (non-urgent,=20 > >>normal, urgent,=20 > >>emergency) to numeric values (10, 20, 30, 40) so that callerprefs=20 > >>matching on ranges would be possible. The description says > >> > >> "A value of X means that the device is willing to > >> take requests with priority X and higher." > >> > >>However no actual examples are given, and the above description is=20 > >>slightly at odds with the way numeric values are to be handled with=20 > >>feature params. To get as close as possible to the above, and use=20 > >>numeric values so that callerprefs matching works, a value=20 > of normal=20 > >>ought to be represented as: > >> > >> priority=3D"#>=3D20" > >> > >>If instead it were simply represented as priority=3D"20" then=20 > >>the 20 would=20 > >>simply be a token, and callerprefs range matching would not work. > >=20 > >=20 > > yes, you are right.=20 > > =20 > >=20 > >>The impact of this on prescaps is the value of priority=20 > should permit=20 > >>one or more numeric ranges. (Negation is also permitted, but=20 > >>that can be=20 > >>mapped into a different set of ranges.) > >=20 > >=20 > > Right, and in practice this means that we need to be able=20 > to represent comparison operators =3D, >=3D, and <=3D and also=20 > numeric ranges. I don't this we actually need to use # here=20 > as there should not any change to confuse this value to a=20 > token or to a string. I can think of following solutions: > >=20 > > 1) > > add a operation parameter into element. With=20 > this we would have something like > > priority values =3D, >=3D, <=3D and range. Only ugly think with this is the=20 > range. We would need to give range for example using similar=20 > syntax as in callee caps: 4/8. This will also have an effect=20 > that priority needs to be a string type element. > >=20 > > 2) > > Use substitutiongroups as is already done in some other=20 > elements defined in prescaps. Schema would look something=20 > like (this has not been validated): > > > > > > > ref=3D"tns:prioritytypes" > > maxOccurs=3D"1"/> > > > > > > > > substitutionGroup=3D"tns:prioritytypes"/> > > substitutionGroup=3D"tns:priorityypes"/> > > and so on > >=20 > > Solution 1 would be somewhat simpler. Solution 2 would=20 > allow us to use correct types for priorities and it would be=20 > consistent with rest of the schema. So I would vote for=20 > option 2. Other solution are also welcome. > > =09 > > - Mikko=20 > >=20 > >=20 > >>I expect this issue will require a bit more discussion. :-( > >> > >> Paul > >> > >> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >> > >> > >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 03:38: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 DAA03812; Mon, 1 Nov 2004 03:38:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXx8-00012r-43; Mon, 01 Nov 2004 03:54:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COXfN-0004Q4-U6; Mon, 01 Nov 2004 03:35:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COXXB-0002rH-4c for simple@megatron.ietf.org; Mon, 01 Nov 2004 03:27: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 DAA02462 for ; Mon, 1 Nov 2004 03:27:24 -0500 (EST) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXm2-0000ff-GB for simple@ietf.org; Mon, 01 Nov 2004 03:42:47 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA18RCl06725; Mon, 1 Nov 2004 10:27:13 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 10:24:44 +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 iA18OikN010121; Mon, 1 Nov 2004 10:24:44 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00gNR0jH; Mon, 01 Nov 2004 10:24:33 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 iA18CFa03723; Mon, 1 Nov 2004 10:12:15 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 10:08:24 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 10:08:23 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 10:08:23 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Presence Authorization Discussion E: Subscriptionpolicyvs. document processing Date: Mon, 1 Nov 2004 10:08:23 +0200 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8BE8@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Presence Authorization Discussion E: Subscriptionpolicyvs. document processing Thread-Index: AcSv2ZI6QOUuij/1QzuNAbt3f/pJyANERKPAAD64R6AAgQH0EA== To: , , X-OriginalArrivalTime: 01 Nov 2004 08:08:23.0967 (UTC) FILETIME=[F57642F0:01C4BFE9] X-Spam-Score: 0.3 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Boyer, David G (Dave) [mailto:dgboyer@avaya.com] > Sent: 29.October.2004 21:47 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); jdrosen@dynamicsoft.com; > pkyzivat@cisco.com > Cc: simple@ietf.org; Boyer, David G (Dave) > Subject: RE: [Simple] Presence Authorization Discussion E: > Subscriptionpolicyvs. document processing >=20 >=20 > Hisham - >=20 > Comments inline. >=20 > Dave >=20 > > -----Original Message----- > > From: simple-bounces@ietf.org=20 > > [mailto:simple-bounces@ietf.org]On Behalf > > Of hisham.khartabil@nokia.com > > Sent: Thursday, October 28, 2004 8:41 AM > > To: jdrosen@dynamicsoft.com; pkyzivat@cisco.com > > Cc: simple@ietf.org > > Subject: RE: [Simple] Presence Authorization Discussion E: > > Subscriptionpolicyvs. document processing > >=20 > >=20 > > I have some concerns about having a watcher dependent policy=20 > > as you describe it. Your model suggests that a presentity=20 > > needs to assign composition policies to watchers. I do not=20 > > like that at all. >=20 > Many users of a presence system insist on being able to control > who is allowed to view their presence data. Watcher specific > filtering is necessary because a given user may want (or may > be required to) their boss to always see their presence state > and may only want certain business associates or colleagues > to only be aware of their office phone 9 - 5 during the work > week. I wasn't talking about privacy filtering. I was talking about = composition policy. > >=20 > > The other concern that I have with this is that if the first=20 > > composition policy is watcher dependent, then it means that a=20 > > presence server cannot process presence documents to compose=20 > > a raw presence document until a subscription has arrived. It=20 > > also requires the presence server to keep a raw presence=20 > > document for every subscriber. I prefer one raw presence=20 > > document for the privacy rules to work with, but I can be=20 > > convinced otherwise if I am presented with compelling reasons :) >=20 > The latest draft of the datamodel says - > This document is "raw" because it > contains more information than any watcher might actually see. > Privacy and watcher filtering may eliminate some of the=20 > data from the > document. >=20 > From this I take it that the first composition policy is watcher > independent -=20 No its not currently. > the raw presence document contains unfiltered data > from all presence sources. The "Create View" computation box > confuses me a bit though - The raw presence document that is=20 > the outcome > of this step is not filtered on a per watcher basis. Isn't > a "view" of a raw presence document specific to a watcher(s)? That's the issue that we're trying to address. Is it or is it not. /Hisham >=20 >=20 > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: simple-bounces@ietf.org=20 > > > [mailto:simple-bounces@ietf.org]On Behalf > > > Of ext Jonathan Rosenberg > > > Sent: 11.October.2004 23:24 > > > To: Paul Kyzivat > > > Cc: Simple WG > > > Subject: Re: [Simple] Presence Authorization Discussion E:=20 > > > Subscription > > > policyvs. document processing > > >=20 > > >=20 > > > inline. > > >=20 > > > Paul Kyzivat wrote: > > >=20 > > > > I mostly agree with this partitioning. However I do have=20 > > > one concern.=20 > > > > See below. > > > >=20 > > > > Paul > > > >=20 > > > > Jonathan Rosenberg wrote: > > > >=20 > > > >> This is really the only major open issue that is not=20 > > > resolved by the=20 > > > >> data model, and its one of the most important ones to=20 > > resolve. So,=20 > > > >> please comment on this one. > > > >> > > > >> Currently, our presence authorization policy documents=20 > > > specify how to=20 > > > >> filter presence documents for presentation to a watcher,=20 > > > and they also=20 > > > >> specify whether or not a subscription should be accepted=20 > > > or rejected=20 > > > >> (via the ). They also specify polite-blocking as=20 > > > an action. As=20 > > > >> a result of all of these being actions, there is an=20 > > > explicit privacy=20 > > > >> ordering - block -> confirm -> polite block -> allow. > > > >> > > > >> Henning had suggested on the list that perhaps we should=20 > > split the=20 > > > >> process of acceptance/rejection of the subscription from the=20 > > > >> processing of the document itself. > > > >> > > > >> If anything, the data model would currently argue in=20 > > favor of that=20 > > > >> position. The processing of figure 4 defines the privacy=20 > > filtering=20 > > > >> step as serving the fucntion of removing sensitive=20 > > > information from=20 > > > >> the presence document. This sequence of operations gets=20 > > > applied when a=20 > > > >> document needs to be generated for a watcher. It doesnt=20 > > > address the=20 > > > >> actual acceptance/rejection of the subscription itself. > > > >> > > > >> In fact, its more complicated than that. In light of the=20 > > > data model,=20 > > > >> "polite blocking" is really a combination of accepting of the=20 > > > >> subscription, along with a composition policy which produces a=20 > > > >> document for the watcher that lies about my presence status. > > > >> > > > >> So, the question is, do we keep these concepts combined=20 > > > into a single=20 > > > >> action, or do we split them apart? In either case, how=20 > > > does this play=20 > > > >> in the model? > > > >> > > > >> From a *modeling* perspective, I think that processing of the=20 > > > >> subscription is most definitely a separate thing. That=20 > > > processing puts=20 > > > >> the subscription in only one of three allowed states=20 > (accepted,=20 > > > >> pending, denied). It is only once accepted that the=20 > > actual privacy=20 > > > >> filtering operation makes sense. I'd further argue that=20 > > > the process of=20 > > > >> polite blocking is really only meaningful when the=20 > > > subscription itself=20 > > > >> has been accepted (in the sense that the subscription got=20 > > > a 200 ok and=20 > > > >> a NOTIFY gets sent). It's clearly privacy-related, but its not=20 > > > >> "privacy filtering" in the sense that it is not a process=20 > > > of removing=20 > > > >> information at all, its really creation of a fake input=20 > > > document into=20 > > > >> the processing of figure 4. > > > >=20 > > > >=20 > > > > Yup. > > > >=20 > > > >> So, here is my proposal: > > > >> > > > >> 1. the data model identify an additional processing=20 > step, which=20 > > > >> happens when a subscription arrives. It defines how that=20 > > > subscription=20 > > > >> is procssed (accept, reject, confirm), and it determines the=20 > > > >> composition policy of figure 4. Note that, because=20 > > > composition hasn't=20 > > > >> happened yet, conditions that are based on the presence=20 > > > state itself=20 > > > >> are meaningless and would be ignored. I think this is a=20 > > > feature; it=20 > > > >> means that the state of the subscription itself doesnt=20 > > > really change=20 > > > >> with my presence state, it will be based only on more static=20 > > > >> information, such as the identity of the watcher, time=20 > > of day, etc. > > > >> > > > >> 2. The processing in step 1 above is defined by the=20 > > =20 > > > >> element, as it is today in the authorization document > > > >> > > > >> 3. we separate the processing of subscription handling=20 > > > from privacy=20 > > > >> filtering in the model, but both use the same input=20 > > document - the=20 > > > >> authorization policy. Thus, the element=20 > > is used to=20 > > > >> guide the subscription processing, and the rest is=20 > used to guide=20 > > > >> privacy filtering. This has the benefit of allowing us=20 > a single=20 > > > >> document for a user to manage via xcap, but allowing it=20 > > to really=20 > > > >> represent two separate poliices. > > > >> > > > >> 4. The value of "polite-block" basically selects a=20 > > > composition policy=20 > > > >> which creates a fake document for a user, and "accept"=20 > uses the=20 > > > >> default policy. More generally, we might imagine that=20 > > composition=20 > > > >> policies themselves have privacy implications - some will=20 > > > reveal more,=20 > > > >> and some less. To resolve that, we can give each policy a=20 > > > number based=20 > > > >> on the amount of information it provides, and select which=20 > > > policy as=20 > > > >> part of the element. Beacuse the=20 > > > element=20 > > > >> is combined using the combination rules of common-policy,=20 > > > it has the=20 > > > >> right privacy properties. > > > >=20 > > > >=20 > > > > This relates back to my comment in another thread about=20 > > whether we=20 > > > > really need the composition policy to differ by subscriber.=20 > > > This seems=20 > > > > to suggest that the answer is yes, but the issues of=20 > that remain. > > >=20 > > > Right. Lets debate that in the other thread. > > >=20 > > > >=20 > > > > The data model (figure 4) has the same composition policy=20 > > > being used=20 > > > > *twice* - once to combine all the inputs, and later to=20 > > > patch up any mess=20 > > > > made by the filtering. This always seemed a bit odd to me. > > > >=20 > > > > Maybe the answer is that these should be different=20 > > > policies. The policy=20 > > > > used to combine all the inputs could be common to all=20 > > > subscribers, while=20 > > > > the post-filter policy might differ by subscriber. One of=20 > > > the functions=20 > > > > of this post-filter composition policy could be to do=20 > > > polite blocking. > > >=20 > > > I'm not sure I see how they really differ. Indeed, if we had=20 > > > determined=20 > > > that the scope of functions for composition policy were=20 > > > commutative with=20 > > > filtering, and idempotent, one might conclude that there is=20 > > > no need at=20 > > > all to do it prior to filtering. > > >=20 > > > In any case, I see the scope of composiiton policy being=20 > > guiding the=20 > > > decisions on how services and devices are merged, split, and=20 > > > conflicts=20 > > > are resolved. I don't see how the policies on how this is=20 > > done would=20 > > > really differ based on whether they happen to be executed=20 > > > prior or after=20 > > > privacy and watcher filtering. What logic would one specify=20 > > > differently=20 > > > in one place as opposed to another? > > >=20 > > > -Jonathan R. > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ=20 > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailman-bounces@ietf.org Mon Nov 1 06:54:35 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 GAA20841 for ; Mon, 1 Nov 2004 06:54:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COb0b-0005FB-0B for simple-archive@ietf.org; Mon, 01 Nov 2004 07:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZSo-0002jM-Go for simple-archive@ietf.org; Mon, 01 Nov 2004 05:31:02 -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: Date: Mon, 01 Nov 2004 05:11:41 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list 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 Mon Nov 1 11:02: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 LAA25444; Mon, 1 Nov 2004 11:02:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COesx-00021f-6b; Mon, 01 Nov 2004 11:18:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COdaM-0003Nq-E5; Mon, 01 Nov 2004 09:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COaEo-0000bS-Tm for simple@megatron.ietf.org; Mon, 01 Nov 2004 06:20:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18000 for ; Mon, 1 Nov 2004 06:20:37 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COaTh-0004gG-QE for simple@ietf.org; Mon, 01 Nov 2004 06:36:02 -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 iA1BKLl02204; Mon, 1 Nov 2004 13:20:22 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 13:19: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 iA1BJdXG026000; Mon, 1 Nov 2004 13:19:39 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00PFyu3b; Mon, 01 Nov 2004 13:19:31 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 iA1BJQa22891; Mon, 1 Nov 2004 13:19:26 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 12:24:35 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 12:24:32 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 12:24:32 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt Date: Mon, 1 Nov 2004 12:24:32 +0200 Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt Thread-Index: AcS8PmsFVQAs+EoIR9akPBRU6GuGTwCNXXSQ To: , X-OriginalArrivalTime: 01 Nov 2004 10:24:32.0628 (UTC) FILETIME=[FA5D0340:01C4BFFC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Hi, > Markus.Isomaki@nokia.com wrote: > > Paul, > >=20 > > Do you assume that prescaps would always be generated based=20 > on registration information? >=20 > No. But I think some will do it that way. >=20 > > At least I think in many cases it will be directly=20 > published by the=20 > PUA/device itself, >=20 > Yes, I agree. >=20 > > in which case there obviously won't be a problem in=20 > associating e.g.=20 > mobility with a device. If someone is forming prescaps based on=20 > registered contacts, I suggest to simply leave mobility away,=20 > since as=20 > you say association with any device id could be impossible, and I too=20 > woudn't like to mess the service model by talking about=20 > mobile services. >=20 > I guess leaving mobility out is an option. Not great, but perhaps a=20 > tolerable limitation. >=20 > Paul Yes, it would be nice to have it but I cannot figure out how to do it. Jumping to other topic. Prescaps now defines and = elements that belong to documents. I think these = elements provide useful information but I think that their place is not = exactly in the prescaps I-D. It might make more sense to move them for = example to presence data model (include them into = urn:ietf:params:xml:ns:pidf:device schema). What do you think? - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 11:34: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 LAA29739; Mon, 1 Nov 2004 11:34:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfNK-0003Mw-4b; Mon, 01 Nov 2004 11:49:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COeja-0001Tu-DA; Mon, 01 Nov 2004 11:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COdxj-0000VX-HR for simple@megatron.ietf.org; Mon, 01 Nov 2004 10:19: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 KAA14933 for ; Mon, 1 Nov 2004 10:19:14 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COeCd-0000ob-Bu for simple@ietf.org; Mon, 01 Nov 2004 10:34:40 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2004 10:42:01 -0500 X-BrightmailFiltered: true 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 iA1FIcv7028538; Mon, 1 Nov 2004 10:18:39 -0500 (EST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMR90308; Mon, 1 Nov 2004 10:18:39 -0500 (EST) Message-ID: <418653CF.9050306@cisco.com> Date: Mon, 01 Nov 2004 10:18:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > > Jumping to other topic. > Prescaps now defines and elements that > belong to documents. I think these elements provide > useful information but I think that their place is not exactly > in the prescaps I-D. I agree that these aren't "capabilities". OTOH, these are things that are part of RFC 3840 (callee caps). A case can be made that prescaps is the place to define how everything in 3840 maps to presence. > It might make more sense to move them for example to presence > data model (include them into urn:ietf:params:xml:ns:pidf:device schema). > What do you think? It doesn't matter much to me where the data elements are defined, as long as they are defined somewhere. I don't know if the data model is a very good place - it mainly defines a framework rather than the detailed contents. If not prescaps, then I would think rpid would be the other likely place, or else yet another independent draft. But if these are not defined in prescaps, then I think it would be good for prescaps to cross reference where they are defined. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 11:44: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 LAA00963; Mon, 1 Nov 2004 11:44:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfWt-0003gQ-OW; Mon, 01 Nov 2004 11:59:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COeuE-0008T8-7E; Mon, 01 Nov 2004 11:19:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COeFN-0000wA-QO for simple@megatron.ietf.org; Mon, 01 Nov 2004 10:37:30 -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 KAA20544 for ; Mon, 1 Nov 2004 10:37:28 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COeUI-0001Mv-TM for simple@ietf.org; Mon, 01 Nov 2004 10:52:55 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Nov 2004 10:36:58 -0500 X-BrightmailFiltered: true 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 iA1FarfD026420; Mon, 1 Nov 2004 10:36:56 -0500 (EST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMR91881; Mon, 1 Nov 2004 10:36:53 -0500 (EST) Message-ID: <41865815.5050900@cisco.com> Date: Mon, 01 Nov 2004 10:36:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Presence Authorization Discussion - subscriber dependent composition? References: <5816828233DEFA41807A6CFDFDF2343C3A8BE8@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd Content-Transfer-Encoding: 7bit (Changed to subject to be more specific) I had a discussion with Jonathan about this, and I am coming to agree that letting composition policy be subscriber dependent is probably the right course for us. I had two objections to this: - efficiency - complexity of defining composition policy I have now concluded that the efficiency differences between the two approaches are probably negligible in the overall scheme of things - at least so that it shouldn't be a criterion in the decision. Re complexity of composition policy - I think composition policy is going to be a challenging area in either case. I don't immediately see how to define a policy that does the kinds of things we all hint at, and is at the same time comprehensible to the average user. As a result, I think we will see a lot of experimentation, and lots of policy representations that aren't fully featured. Allowing subscriber dependent policy adds another degree of freedom to this mix. Those who can't cope with it can simply not use that capability. And if they don't, they are free to create implementations that have a single composed document. This will not become an issue until and unless we get to the point of attempting to standardize composition policy. Until then I see no problem in leaving it as a possibility. Paul hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Boyer, David G (Dave) [mailto:dgboyer@avaya.com] >>Sent: 29.October.2004 21:47 >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); jdrosen@dynamicsoft.com; >>pkyzivat@cisco.com >>Cc: simple@ietf.org; Boyer, David G (Dave) >>Subject: RE: [Simple] Presence Authorization Discussion E: >>Subscriptionpolicyvs. document processing >> >> >>Hisham - >> >>Comments inline. >> >>Dave >> >> >>>-----Original Message----- >>>From: simple-bounces@ietf.org >>>[mailto:simple-bounces@ietf.org]On Behalf >>>Of hisham.khartabil@nokia.com >>>Sent: Thursday, October 28, 2004 8:41 AM >>>To: jdrosen@dynamicsoft.com; pkyzivat@cisco.com >>>Cc: simple@ietf.org >>>Subject: RE: [Simple] Presence Authorization Discussion E: >>>Subscriptionpolicyvs. document processing >>> >>> >>>I have some concerns about having a watcher dependent policy >>>as you describe it. Your model suggests that a presentity >>>needs to assign composition policies to watchers. I do not >>>like that at all. >> >>Many users of a presence system insist on being able to control >>who is allowed to view their presence data. Watcher specific >>filtering is necessary because a given user may want (or may >>be required to) their boss to always see their presence state >>and may only want certain business associates or colleagues >>to only be aware of their office phone 9 - 5 during the work >>week. > > > I wasn't talking about privacy filtering. I was talking about composition policy. > > >>>The other concern that I have with this is that if the first >>>composition policy is watcher dependent, then it means that a >>>presence server cannot process presence documents to compose >>>a raw presence document until a subscription has arrived. It >>>also requires the presence server to keep a raw presence >>>document for every subscriber. I prefer one raw presence >>>document for the privacy rules to work with, but I can be >>>convinced otherwise if I am presented with compelling reasons :) >> >>The latest draft of the datamodel says - >>This document is "raw" because it >> contains more information than any watcher might actually see. >> Privacy and watcher filtering may eliminate some of the >>data from the >> document. >> >>From this I take it that the first composition policy is watcher >>independent - > > > No its not currently. > > >>the raw presence document contains unfiltered data >>from all presence sources. The "Create View" computation box >>confuses me a bit though - The raw presence document that is >>the outcome >>of this step is not filtered on a per watcher basis. Isn't >>a "view" of a raw presence document specific to a watcher(s)? > > > That's the issue that we're trying to address. Is it or is it not. > > /Hisham > > >> >>>/Hisham >>> >>> >>>>-----Original Message----- >>>>From: simple-bounces@ietf.org >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>Of ext Jonathan Rosenberg >>>>Sent: 11.October.2004 23:24 >>>>To: Paul Kyzivat >>>>Cc: Simple WG >>>>Subject: Re: [Simple] Presence Authorization Discussion E: >>>>Subscription >>>>policyvs. document processing >>>> >>>> >>>>inline. >>>> >>>>Paul Kyzivat wrote: >>>> >>>> >>>>>I mostly agree with this partitioning. However I do have >>>> >>>>one concern. >>>> >>>>>See below. >>>>> >>>>> Paul >>>>> >>>>>Jonathan Rosenberg wrote: >>>>> >>>>> >>>>>>This is really the only major open issue that is not >>>>> >>>>resolved by the >>>> >>>>>>data model, and its one of the most important ones to >>>>> >>>resolve. So, >>> >>>>>>please comment on this one. >>>>>> >>>>>>Currently, our presence authorization policy documents >>>>> >>>>specify how to >>>> >>>>>>filter presence documents for presentation to a watcher, >>>>> >>>>and they also >>>> >>>>>>specify whether or not a subscription should be accepted >>>>> >>>>or rejected >>>> >>>>>>(via the ). They also specify polite-blocking as >>>>> >>>>an action. As >>>> >>>>>>a result of all of these being actions, there is an >>>>> >>>>explicit privacy >>>> >>>>>>ordering - block -> confirm -> polite block -> allow. >>>>>> >>>>>>Henning had suggested on the list that perhaps we should >>>>> >>>split the >>> >>>>>>process of acceptance/rejection of the subscription from the >>>>>>processing of the document itself. >>>>>> >>>>>>If anything, the data model would currently argue in >>>>> >>>favor of that >>> >>>>>>position. The processing of figure 4 defines the privacy >>>>> >>>filtering >>> >>>>>>step as serving the fucntion of removing sensitive >>>>> >>>>information from >>>> >>>>>>the presence document. This sequence of operations gets >>>>> >>>>applied when a >>>> >>>>>>document needs to be generated for a watcher. It doesnt >>>>> >>>>address the >>>> >>>>>>actual acceptance/rejection of the subscription itself. >>>>>> >>>>>>In fact, its more complicated than that. In light of the >>>>> >>>>data model, >>>> >>>>>>"polite blocking" is really a combination of accepting of the >>>>>>subscription, along with a composition policy which produces a >>>>>>document for the watcher that lies about my presence status. >>>>>> >>>>>>So, the question is, do we keep these concepts combined >>>>> >>>>into a single >>>> >>>>>>action, or do we split them apart? In either case, how >>>>> >>>>does this play >>>> >>>>>>in the model? >>>>>> >>>>>> From a *modeling* perspective, I think that processing of the >>>>>>subscription is most definitely a separate thing. That >>>>> >>>>processing puts >>>> >>>>>>the subscription in only one of three allowed states >>>>> >>(accepted, >> >>>>>>pending, denied). It is only once accepted that the >>>>> >>>actual privacy >>> >>>>>>filtering operation makes sense. I'd further argue that >>>>> >>>>the process of >>>> >>>>>>polite blocking is really only meaningful when the >>>>> >>>>subscription itself >>>> >>>>>>has been accepted (in the sense that the subscription got >>>>> >>>>a 200 ok and >>>> >>>>>>a NOTIFY gets sent). It's clearly privacy-related, but its not >>>>>>"privacy filtering" in the sense that it is not a process >>>>> >>>>of removing >>>> >>>>>>information at all, its really creation of a fake input >>>>> >>>>document into >>>> >>>>>>the processing of figure 4. >>>>> >>>>> >>>>>Yup. >>>>> >>>>> >>>>>>So, here is my proposal: >>>>>> >>>>>>1. the data model identify an additional processing >>>>> >>step, which >> >>>>>>happens when a subscription arrives. It defines how that >>>>> >>>>subscription >>>> >>>>>>is procssed (accept, reject, confirm), and it determines the >>>>>>composition policy of figure 4. Note that, because >>>>> >>>>composition hasn't >>>> >>>>>>happened yet, conditions that are based on the presence >>>>> >>>>state itself >>>> >>>>>>are meaningless and would be ignored. I think this is a >>>>> >>>>feature; it >>>> >>>>>>means that the state of the subscription itself doesnt >>>>> >>>>really change >>>> >>>>>>with my presence state, it will be based only on more static >>>>>>information, such as the identity of the watcher, time >>>>> >>>of day, etc. >>> >>>>>>2. The processing in step 1 above is defined by the >>>>> >>> >>> >>>>>>element, as it is today in the authorization document >>>>>> >>>>>>3. we separate the processing of subscription handling >>>>> >>>>from privacy >>>> >>>>>>filtering in the model, but both use the same input >>>>> >>>document - the >>> >>>>>>authorization policy. Thus, the element >>>>> >>>is used to >>> >>>>>>guide the subscription processing, and the rest is >>>>> >>used to guide >> >>>>>>privacy filtering. This has the benefit of allowing us >>>>> >>a single >> >>>>>>document for a user to manage via xcap, but allowing it >>>>> >>>to really >>> >>>>>>represent two separate poliices. >>>>>> >>>>>>4. The value of "polite-block" basically selects a >>>>> >>>>composition policy >>>> >>>>>>which creates a fake document for a user, and "accept" >>>>> >>uses the >> >>>>>>default policy. More generally, we might imagine that >>>>> >>>composition >>> >>>>>>policies themselves have privacy implications - some will >>>>> >>>>reveal more, >>>> >>>>>>and some less. To resolve that, we can give each policy a >>>>> >>>>number based >>>> >>>>>>on the amount of information it provides, and select which >>>>> >>>>policy as >>>> >>>>>>part of the element. Beacuse the >>>>> >>>> element >>>> >>>>>>is combined using the combination rules of common-policy, >>>>> >>>>it has the >>>> >>>>>>right privacy properties. >>>>> >>>>> >>>>>This relates back to my comment in another thread about >>>> >>>whether we >>> >>>>>really need the composition policy to differ by subscriber. >>>> >>>>This seems >>>> >>>>>to suggest that the answer is yes, but the issues of >>>> >>that remain. >> >>>>Right. Lets debate that in the other thread. >>>> >>>> >>>>>The data model (figure 4) has the same composition policy >>>> >>>>being used >>>> >>>>>*twice* - once to combine all the inputs, and later to >>>> >>>>patch up any mess >>>> >>>>>made by the filtering. This always seemed a bit odd to me. >>>>> >>>>>Maybe the answer is that these should be different >>>> >>>>policies. The policy >>>> >>>>>used to combine all the inputs could be common to all >>>> >>>>subscribers, while >>>> >>>>>the post-filter policy might differ by subscriber. One of >>>> >>>>the functions >>>> >>>>>of this post-filter composition policy could be to do >>>> >>>>polite blocking. >>>> >>>>I'm not sure I see how they really differ. Indeed, if we had >>>>determined >>>>that the scope of functions for composition policy were >>>>commutative with >>>>filtering, and idempotent, one might conclude that there is >>>>no need at >>>>all to do it prior to filtering. >>>> >>>>In any case, I see the scope of composiiton policy being >>> >>>guiding the >>> >>>>decisions on how services and devices are merged, split, and >>>>conflicts >>>>are resolved. I don't see how the policies on how this is >>> >>>done would >>> >>>>really differ based on whether they happen to be executed >>>>prior or after >>>>privacy and watcher filtering. What logic would one specify >>>>differently >>>>in one place as opposed to another? >>>> >>>>-Jonathan R. >>>>-- >>>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>>Chief Technology Officer Parsippany, NJ >>> >>>07054-2711 >>> >>>>dynamicsoft >>>>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>>http://www.jdrosen.net PHONE: (973) 952-5000 >>>>http://www.dynamicsoft.com >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 11:57: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 LAA02495; Mon, 1 Nov 2004 11:57:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfjX-000467-NV; Mon, 01 Nov 2004 12:12:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COf3y-0007Fu-P6; Mon, 01 Nov 2004 11:29:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COecZ-0003NU-OW for simple@megatron.ietf.org; Mon, 01 Nov 2004 11:01: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 LAA25047 for ; Mon, 1 Nov 2004 11:01:26 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COerV-0001vz-Ep for simple@ietf.org; Mon, 01 Nov 2004 11:16:53 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2004 11:24:15 -0500 X-BrightmailFiltered: true 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 iA1F0sv7009735; Mon, 1 Nov 2004 10:00:54 -0500 (EST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMR94076; Mon, 1 Nov 2004 11:00:53 -0500 (EST) Message-ID: <41865DB5.3040505@cisco.com> Date: Mon, 01 Nov 2004 11:00:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] prescaps and priority (Was: I-DACTION:draft-ietf-simple-prescaps-ext-02.txt) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: >>Mikko, >> >>My xml skills are still limited, so I'm not sure what a use >>of (2) would >>look like, but (1) certainly looks ugly. >>Can we just discuss how a usage would look first, and then figure out >>how to declare it? >> >>Odd as it is, it is legal to say something like >> priority="#<=10,#=30, #>=40, #45:50" > > > Yes, it is a bit odd. > > >>I see that as a worst case. So I will use that to work with. >>I think the >>following might at least read nicely: >> >> >> >> >> >> >> >> >>An advantage of the above is that the simple cases really are simple. >>What do you think of that? > > > Yes, that doesn't look bad at all. I would still like to add bit more syntax into it as follows: I can live with either of these. I guess they are more in keeping with the overall style. Paul > > > > > > > > > or > > > > > > > > > > > This way all priority values would be enclosed inside a single element. > > - Mikko > > >> Paul >> >>mikko.lonnfors@nokia.com wrote: >> >>>Hi, >>> >>>inline >>> >>> >>> >>>>I also see another issue that I should have caught before, >>> >>because it >> >>>>isn't new. And it is as much a problem for RFC3840 as it is a >>>>problem here: >>>> >>>>The issue is how priority is represented. As part of doing 3840, >>>>priority was changed from a set of tokens (non-urgent, >>>>normal, urgent, >>>>emergency) to numeric values (10, 20, 30, 40) so that callerprefs >>>>matching on ranges would be possible. The description says >>>> >>>> "A value of X means that the device is willing to >>>> take requests with priority X and higher." >>>> >>>>However no actual examples are given, and the above description is >>>>slightly at odds with the way numeric values are to be handled with >>>>feature params. To get as close as possible to the above, and use >>>>numeric values so that callerprefs matching works, a value >>> >>of normal >> >>>>ought to be represented as: >>>> >>>> priority="#>=20" >>>> >>>>If instead it were simply represented as priority="20" then >>>>the 20 would >>>>simply be a token, and callerprefs range matching would not work. >>> >>> >>>yes, you are right. >>> >>> >>> >>>>The impact of this on prescaps is the value of priority >>> >>should permit >> >>>>one or more numeric ranges. (Negation is also permitted, but >>>>that can be >>>>mapped into a different set of ranges.) >>> >>> >>>Right, and in practice this means that we need to be able >> >>to represent comparison operators =, >=, and <= and also >>numeric ranges. I don't this we actually need to use # here >>as there should not any change to confuse this value to a >>token or to a string. I can think of following solutions: >> >>>1) >>>add a operation parameter into element. With >> >>this we would have something like >> >>>priority> >>values =, >=, <= and range. Only ugly think with this is the >>range. We would need to give range for example using similar >>syntax as in callee caps: 4/8. This will also have an effect >>that priority needs to be a string type element. >> >>>2) >>>Use substitutiongroups as is already done in some other >> >>elements defined in prescaps. Schema would look something >>like (this has not been validated): >> >>> >>> >>> >> ref="tns:prioritytypes" >>> maxOccurs="1"/> >>> >>> >>> >>> > >>substitutionGroup="tns:prioritytypes"/> >> >>> > >>substitutionGroup="tns:priorityypes"/> >> >>> and so on >>> >>>Solution 1 would be somewhat simpler. Solution 2 would >> >>allow us to use correct types for priorities and it would be >>consistent with rest of the schema. So I would vote for >>option 2. Other solution are also welcome. >> >>> >>>- Mikko >>> >>> >>> >>>>I expect this issue will require a bit more discussion. :-( >>>> >>>> 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 >> > > > _______________________________________________ > 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 Nov 1 12:03: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 MAA03628; Mon, 1 Nov 2004 12:03:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfpl-0004IE-AB; Mon, 01 Nov 2004 12:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COf9g-0001WE-BO; Mon, 01 Nov 2004 11:35:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COekn-0002Du-Ft for simple@megatron.ietf.org; Mon, 01 Nov 2004 11:09: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 LAA26677 for ; Mon, 1 Nov 2004 11:09:56 -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 1COezi-0002Oa-DO for simple@ietf.org; Mon, 01 Nov 2004 11:25:23 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2004 08:19:29 -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 iA1G9GnC025340; Mon, 1 Nov 2004 08:09:17 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMR94935; Mon, 1 Nov 2004 11:09:21 -0500 (EST) Message-ID: <41865FB1.7080700@cisco.com> Date: Mon, 01 Nov 2004 11:09:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Prescaps rep of token types X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit I like the change in the representation for token-valued features, to the form that has and elements. However, I am concerned about defining xml elements for each token. This begins to look like ASN.1 that most people seem to hate. It requires an excessive amount of schema definition, and makes it impossible to represent a value for which no schema definition is present. I think it would be preferable to define them all the way is defined, with the individual tokens simply being defined as strings. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 12:06: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 MAA04078; Mon, 1 Nov 2004 12:06:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfs2-0004PI-Pf; Mon, 01 Nov 2004 12:21:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfHs-0006eL-Qe; Mon, 01 Nov 2004 11:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COetf-0008A0-4p for simple@megatron.ietf.org; Mon, 01 Nov 2004 11:19:07 -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 LAA27645 for ; Mon, 1 Nov 2004 11:19:05 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COf8Z-0002iA-Sl for simple@ietf.org; Mon, 01 Nov 2004 11:34:33 -0500 Received: from [192.168.1.158] (ip-69-33-98-226.sea.megapath.net [69.33.98.226]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA1GJ0Ss027724 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 1 Nov 2004 10:19:03 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) To: simple@ietf.org Message-Id: From: Robert Sparks Date: Mon, 1 Nov 2004 10:19:00 -0600 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [Simple] IETF61 SIMPLE agenda X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688948504==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 --===============0688948504== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-27-759656382; protocol="application/pkcs7-signature" --Apple-Mail-27-759656382 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Folks - Here's the current plan for our meetings in DC. Feel free to suggest adjustments. RjS SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) IETF61 Tuesday, November 9, 2004 1545-1645 Afternoon Session III and 1700-1800 Afternoon Session IV 15m Administrivia - Chairs 1h MSRP - Ben Campbell, Cullen Jennings http://www.ietf.org/internet-drafts/draft-ietf-simple-message- sessions-09.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays -02.txt 30m Presence Rules - Jonathan Rosenberg http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules -01.txt Wednesday, November 10, 2004 0900-1130 Morning Session 1h 45m Presence Data Model / RPID - Jonathan Rosenberg, Henning Schulzrinne http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data- model-01.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-04.txt 30m Partial Notify/Publish - Aki Niemi, Mikko Lonnfors http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- publish-01.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf- format-02.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify -03.txt 15m Prescaps - Mikko Lonnfors http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext -02.txt --Apple-Mail-27-759656382 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAw1F7jANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDIxMTQwNjIxWhcNMDUxMDIxMTQwNjIxWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRyanNwYXJrc0Bub3N0cnVt LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjqlA5TN+Vdj5RphuzqAiHDB0zZ 9Oi9WJXz6ViFehCpDYiT/eunO0rur7F+aEb0MnrnLbGm9XJbADwxdKkkvIZ6T5nGJkoALlqCgivE Ln4jV3pagvgbLB3QEHJkdc0FPfdltOEWBy5bTZdx1QaUuMwA5J0TiBaKtEuYezzmMd+/T6G0tNix 7o2e2EgcO1MvymeJ76oxbSEvut5O+mRBbKF3qe3rwyEyTZcYiKFKZga/a3t4rfjhmnzV2AtWn6DG 4Xl8A/kwnucG3tRfx5NNmLECRAwXem32xMUi7ub6cuwtT0gq1C6StGHkQJrnpjsEEs5bKz75bkZd VFr+GpM9Xa0CAwEAAaMxMC8wHwYDVR0RBBgwFoEUcmpzcGFya3NAbm9zdHJ1bS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCvd7akpvkndBIF5pJFS8+2FLGAvELO2VyO8m2dZ9IP xsu+dpi1UeAvDyx0WnuGwOmGHdqYueVaiRhr6zGljRW2R3i5NNe3svPHDDiIGTHzwaEGVd37aT+e UH7EuTz97/L+A93b0lMvpheB8WsKItqmjqDVCwMlMZS4gFtG3iwl0zCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDUXuMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTEwMTE2MTkwMFowIwYJKoZIhvcNAQkEMRYEFMi9 MYx1dmKTuKCUj/ygpVoyJuPjMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNRe4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDUXuMA0GCSqGSIb3DQEBAQUABIIBAGBR YHcSKGfBu/dLozZNYhku2CZxL8dUrbP7/SC+6LF2oAChkGIeRO3vuAVJ/XpH8mZqvntn6PYawCNu bDZRu5n186S87HTv5+ud7qv+NHgEfsY1spWiJdRwKtHE/758HaJ2JrjWv4ndNaiSyQhb9jrWvm+H q7PlRXPDLFvX/ntt3BIu/lkHIWUfHJvo/qAVUU4sQH4IQM3aHHRAoXFIMglHyOx7bflRRMZ/m+hU mDPoMJj0QaWYvjaF5sczHLSqTGbxc1VHccKz1jT0wLUKME5bXXlEkFKJ/xIMDL9U0Dt/FfGNzNOQ R8RdlHhjebWXf6hPQMlz+ei/gmEB5lklgCMAAAAAAAA= --Apple-Mail-27-759656382-- --===============0688948504== 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 --===============0688948504==-- From simple-bounces@ietf.org Mon Nov 1 14:21: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 OAA19628; Mon, 1 Nov 2004 14:21:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhz8-0000OD-Tx; Mon, 01 Nov 2004 14:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhW9-0000Vj-O2; Mon, 01 Nov 2004 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COh7a-0006q8-Q5 for simple@megatron.ietf.org; Mon, 01 Nov 2004 13:41: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 NAA16440 for ; Mon, 1 Nov 2004 13:41:36 -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 1COhMW-0007td-On for simple@ietf.org; Mon, 01 Nov 2004 13:57:06 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2004 10:53:26 -0800 X-BrightmailFiltered: true 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 iA1If2cp021849; Mon, 1 Nov 2004 10:41:03 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMS09475; Mon, 1 Nov 2004 13:41:02 -0500 (EST) Message-ID: <4186833E.3070108@cisco.com> Date: Mon, 01 Nov 2004 13:41:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <1098274146.18584.58.camel@hed039-183.research.nokia.com> <41774342.4020008@dynamicsoft.com> <1098709034.5794.55.camel@hed039-183.research.nokia.com> <417D7C0B.9020806@cisco.com> <1098789320.15902.192.camel@hed039-183.research.nokia.com> <417E65A3.6080802@cisco.com> <4185A94B.4080303@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: ext Jonathan Rosenberg , Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Paul Kyzivat wrote: > >> It matters because if you allow it then you entirely gut the semantics >> of the capability descriptions. Including a capability for voice and a >> capability for video could either mean: >> >> - I can do Voice alone, Video alone, or Voice and Video together >> - I can do Voice alone, or Video alone >> >> These make a big difference to the watcher that wants to do voice and >> video together. Ambiguity here is a bad thing. > > > The current capability description does not, as far as I can tell, allow > you to discriminate concurrent capabilities from alternative > capabilities. There is no way to express that "if you ask for video, my > CPU power no longer allows (say, high-fidelity) audio". It is limited. As I (one of the authors) understand and intended it, the capabilities represented by independent feature-params should be interpretted as concurrent capabilities. (Multiple values of the same feature-param represent alternative capabilities.) This interpretation is required for the matching algorithm in callerprefs to make any sense. It is an unfortunate limitation, since there are reasons to want to express both notions. But it was a limitation of the notation at hand, and a desire not to complicate it further. Alternative capabilities can be represented by using different contact addresses that happen to be handled by the same server. (A kludge, but it can work.) After realizing this limitation was not going to be easily fixed there, I was somewhat comforted by the expectation that we could do better with presence, where the notation is not so limited. We now seem to be in a situation were we haven't solved the problem in presence either. I hope to come back to that. But we don't solve the problem by pretending there is no difference between alternative and simultaneous capabilities. >> We agreed some time ago that the address in the tuple SHOULD, without >> further qualification on the caller's part, get you to a UAS that has >> the stated capabilities. > > There are two cases: > > (1) The watcher/caller doesn't know anything about caller preferences > (which seems to be the one you're referring to). > > (2) The watcher/caller does have this capability > In case (1), you will always have this problem if there are multiple UAs > with diverse capabilities "hiding" behind a single AOR. Merging the > capabilities at the PA doesn't solve the problem, as you've now simply > created a union of capabilities that, as such, does not exist. > A receiver of this information can easily do the same union of > capabilities if it wants to, but is has additional information that > there may not actually be an entity that has the combined capabilities. > Again, by not throwing away information, you allow the watcher to make > more intelligent decisions. > > In case (2), the watcher can indeed disambiguate the UAs behind the AOR. Diverse UAs hiding behind a common address (the AOR) is a problem. The general solution to this is "don't do it". Publishing this as two tuples with the same AOR isn't better than merging them as one. Long ago you spelled out the trick to merging these - say nothing about those features where there is ambiguity. In principle, if they are published as separate tuples, then a watcher could reach the right one by both using the address and including explicit callerprefs to select the features desired among those advertised. But We have agreed it is unreasonable to expect watchers to do that. Here is an example of this case: - UA1 supports simultaneous voice and video, no IM. - UA2 supports simultaneous voice and IM, no video. - Both are registered with AOR of sip:alice@atlanta.com. - Both publish presence with their capabilities, using only their AOR as the address. - Bob is a watcher of Alice. - Assume Bob receives two tuples for alice, as above. - Bob wants a videophone call with Alice, so he selects the voice+video tuple from his videophone and selects "call". - The phone sends an invite with offers for voice and video to Alice's AOR. - The invite is forked to UA1 and UA2. Both find it acceptable and ring. - Alice happens to answer UA2. - Bob ends up with a voice-only call. You fix this in a few ways: - You insist that distinct addresses be used - You require every call to include callerprefs for every capability it may want to use. I thought we had agreed that distinct addresses must be used in this case - I just don't think it is reasonable to expect that callers will insert the callerprefs, or that proxies will necessarily honor them. This does however put us between a rock and a hard place if UAs do this, even though it is wrong. Putting both tuples into the final document isn't an accurate representation of the situation, nor is having the most recent one override the older one. The only accurate composition policy is to merge them, deleting conflicting attributes, but that isn't especially satisfying either. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 14:32: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 OAA20646; Mon, 1 Nov 2004 14:32:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COi9m-0000fm-Ns; Mon, 01 Nov 2004 14:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhg8-0007IR-AR; Mon, 01 Nov 2004 14:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhUN-0008J6-QL for simple@megatron.ietf.org; Mon, 01 Nov 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 OAA18189 for ; Mon, 1 Nov 2004 14:05:09 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhjJ-0008QG-Tf for simple@ietf.org; Mon, 01 Nov 2004 14:20:39 -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 iA1J51l02923; Mon, 1 Nov 2004 21:05:01 +0200 (EET) X-Scanned: Mon, 1 Nov 2004 21:04:32 +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 iA1J4WUC007104; Mon, 1 Nov 2004 21:04:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00n40Fmk; Mon, 01 Nov 2004 21:04:31 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1J4Ua14131; Mon, 1 Nov 2004 21:04:30 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 21:04:30 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 21:04:30 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Prescaps rep of token types Date: Mon, 1 Nov 2004 21:04:25 +0200 Message-ID: Thread-Topic: [Simple] Prescaps rep of token types Thread-Index: AcTANRywWR7G25pnQTydiiQrYyUT9AAD6TEA To: X-OriginalArrivalTime: 01 Nov 2004 19:04:30.0881 (UTC) FILETIME=[9DF8A110:01C4C045] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable inline >=20 > I like the change in the representation for token-valued features, to=20 > the form that has and elements. Nice to hear that=20 > However, I am concerned about defining xml elements for each=20 > token. This=20 > begins to look like ASN.1 that most people seem to hate. It=20 > requires an=20 > excessive amount of schema definition, and makes it impossible to=20 > represent a value for which no schema definition is present. > > I think it would be preferable to define them all the way=20 > is=20 > defined, with the individual tokens simply being defined as strings. What you state above regarding new schema definitions is true. However, = this has been discussed before and the conclusion was that we should go = for the model that is now written in the ID. We have had the = type schema definition in the past but most people preferred the current = one. - Mikko =20 > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 16:50: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 QAA08044; Mon, 1 Nov 2004 16:50:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkJG-0004zr-Cu; Mon, 01 Nov 2004 17:05:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COj1j-0005Zt-Uj; Mon, 01 Nov 2004 15:43:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COiiY-00081t-2A for simple@megatron.ietf.org; Mon, 01 Nov 2004 15:23: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 PAA26835 for ; Mon, 1 Nov 2004 15:23:51 -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 1COixV-0001vu-75 for simple@ietf.org; Mon, 01 Nov 2004 15:39:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2004 12:33:27 -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 iA1KMmnC016289; Mon, 1 Nov 2004 12:22:48 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-224.cisco.com [10.21.96.224]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL44325; Mon, 1 Nov 2004 12:23:18 -0800 (PST) Message-ID: <41869B35.20005@cisco.com> Date: Mon, 01 Nov 2004 15:23:17 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <1098274146.18584.58.camel@hed039-183.research.nokia.com> <41774342.4020008@dynamicsoft.com> <1098709034.5794.55.camel@hed039-183.research.nokia.com> <417D7C0B.9020806@cisco.com> <1098789320.15902.192.camel@hed039-183.research.nokia.com> In-Reply-To: <1098789320.15902.192.camel@hed039-183.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: ext Paul Kyzivat , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit inline. Aki Niemi wrote: > Inline. > > On Tue, 2004-10-26 at 01:19, ext Paul Kyzivat wrote: > >>>However, in the absence of GRUU, the only way currently to represent two >>>different SIP-based services is to split them into two tuples that have >>>the corresponding service characteristics with an AoR contact. This in >>>itself is maybe not that useful, except when you want the services to >>>have different status. For example, I'm CLOSED for PoC, but OPEN for IM. >>>This is where override is not at all what we want. >> >>Are these really two distinct UAs, each with a unique contact uri? (Even >>if you don't want to expose it.) >> >>Or are these just two capabilities of the same UA? > > > Why does that matter? They could be the same UA, or separate UAs on the > same device, or separate UAs on the same device that use a front-end > server that dispatches requests to the appropriate handler UA (both > would still have their own contact URIs when sending requests, same IP > address different ports); or they could be separate UAs on different > devices. > > Even though I'm mainly after something along the lines of the first > three rather than the last, I don't see what difference it makes. Let me explain some of the motivation for why the data model says to use gruu. The idea is that each agent providing a service should only publish based on its own view of the service it offers. That is, it shouldn't assume that it knows anything about other services on the same AOR, or know what the compositor is doing. The publication from the agent should say, "when you hit this URI, this is the service you get". If the URI is the AOR, it can't make definitive statements like this, since it doesnt know what other devices are attached to the AOR. The only thing the PUA does know definitively is the service offered by itself, which is addressable by its GRUU. As such, if I have SIP clients on different devices, even if they are behind the same AOR after composition, each of those clients won't know that, and as such, would need to publish information about themselves via their gruu. The compositor can aggregate these together because the registration state provides the AOR/GRUU bindings. > > >>In the latter case, that isn't two services. It is one service, that is >>sometimes capable of both PoC and IM, sometimes one or the other, and >>sometimes none. If the UA is capable of *either* PoC or IM, but not both >>concurrently, then this is the OR-of-ANDs problem, for which two tuples >>with the same address *may* be a solution. (If we have a different >>solution for overriding.) > > > Right. This is mainly what I am after. I don't like the idea of using multiple services to address a limitation in our current ability to represent more complex capability sets. -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 Nov 1 16:52: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 QAA08523; Mon, 1 Nov 2004 16:52:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkLi-00057E-Lp; Mon, 01 Nov 2004 17: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 1COjd9-00081m-Hx; Mon, 01 Nov 2004 16:22:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COiqx-0006M5-7o for simple@megatron.ietf.org; Mon, 01 Nov 2004 15:32: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 PAA27758 for ; Mon, 1 Nov 2004 15:32:32 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COj5v-00029H-9T for simple@ietf.org; Mon, 01 Nov 2004 15:48:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 01 Nov 2004 12:34:41 -0800 X-BrightmailFiltered: true 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 iA1KW0JZ028113; Mon, 1 Nov 2004 12:32:01 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-224.cisco.com [10.21.96.224]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL44884; Mon, 1 Nov 2004 12:31:59 -0800 (PST) Message-ID: <41869D3E.1060004@cisco.com> Date: Mon, 01 Nov 2004 15:31:58 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <1098274146.18584.58.camel@hed039-183.research.nokia.com> <41774342.4020008@dynamicsoft.com> <1098709034.5794.55.camel@hed039-183.research.nokia.com> <417D7C0B.9020806@cisco.com> <1098789320.15902.192.camel@hed039-183.research.nokia.com> <417E65A3.6080802@cisco.com> <4185A94B.4080303@cs.columbia.edu> <4186833E.3070108@cisco.com> In-Reply-To: <4186833E.3070108@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: ext Jonathan Rosenberg , SIMPLE WG , Aki Niemi , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Henning Schulzrinne wrote: > >> Paul Kyzivat wrote: >> >>> It matters because if you allow it then you entirely gut the >>> semantics of the capability descriptions. Including a capability for >>> voice and a capability for video could either mean: >>> >>> - I can do Voice alone, Video alone, or Voice and Video together >>> - I can do Voice alone, or Video alone >>> >>> These make a big difference to the watcher that wants to do voice and >>> video together. Ambiguity here is a bad thing. >> >> >> >> The current capability description does not, as far as I can tell, >> allow you to discriminate concurrent capabilities from alternative >> capabilities. There is no way to express that "if you ask for video, >> my CPU power no longer allows (say, high-fidelity) audio". > > > It is limited. As I (one of the authors) understand and intended it, the > capabilities represented by independent feature-params should be > interpretted as concurrent capabilities. (Multiple values of the same > feature-param represent alternative capabilities.) > > This interpretation is required for the matching algorithm in > callerprefs to make any sense. It is an unfortunate limitation, since > there are reasons to want to express both notions. But it was a > limitation of the notation at hand, and a desire not to complicate it > further. Alternative capabilities can be represented by using different > contact addresses that happen to be handled by the same server. (A > kludge, but it can work.) > > After realizing this limitation was not going to be easily fixed there, > I was somewhat comforted by the expectation that we could do better with > presence, where the notation is not so limited. We now seem to be in a > situation were we haven't solved the problem in presence either. I hope > to come back to that. But we don't solve the problem by pretending there > is no difference between alternative and simultaneous capabilities. > >>> We agreed some time ago that the address in the tuple SHOULD, without >>> further qualification on the caller's part, get you to a UAS that has >>> the stated capabilities. >> >> >> There are two cases: >> >> (1) The watcher/caller doesn't know anything about caller preferences >> (which seems to be the one you're referring to). >> >> (2) The watcher/caller does have this capability > > >> In case (1), you will always have this problem if there are multiple >> UAs with diverse capabilities "hiding" behind a single AOR. Merging >> the capabilities at the PA doesn't solve the problem, as you've now >> simply created a union of capabilities that, as such, does not exist. I think the answer here is that you wouldn't try to represent these capabilities in the merged tuple. If there are capabilities not in common between the two, you'd probably drop them altogether. > > >> A receiver of this information can easily do the same union of >> capabilities if it wants to, but is has additional information that >> there may not actually be an entity that has the combined >> capabilities. Again, by not throwing away information, you allow the >> watcher to make more intelligent decisions. >> >> In case (2), the watcher can indeed disambiguate the UAs behind the AOR. > > > Diverse UAs hiding behind a common address (the AOR) is a problem. The > general solution to this is "don't do it". I think its not reasonable to prohibit this; I think it will be a common case. The answer, as I stated above, is to simply discard any capability indicators not shared across the component services. You need to maintain the property that the characteristics included in the tuple provide a "loose contract" for what you'll get when you invoke that URI. > > Publishing this as two tuples with the same AOR isn't better than > merging them as one. Long ago you spelled out the trick to merging these > - say nothing about those features where there is ambiguity. Right. > This does however put us between a rock and a hard place if UAs do this, > even though it is wrong. Putting both tuples into the final document > isn't an accurate representation of the situation, nor is having the > most recent one override the older one. The only accurate composition > policy is to merge them, deleting conflicting attributes, but that isn't > especially satisfying either. I'm not sure I see a better alternative. -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 Nov 1 16:53: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 QAA08571; Mon, 1 Nov 2004 16:53:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkLx-00057n-SN; Mon, 01 Nov 2004 17:08:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COjdE-00085x-Gy; Mon, 01 Nov 2004 16:22:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COiue-0000Rz-Pc for simple@megatron.ietf.org; Mon, 01 Nov 2004 15:36: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 PAA28184 for ; Mon, 1 Nov 2004 15:36:21 -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 1COj9b-0002EU-TY for simple@ietf.org; Mon, 01 Nov 2004 15:51:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2004 12:48:11 -0800 X-BrightmailFiltered: true 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 iA1KZfom022720; Mon, 1 Nov 2004 12:35:41 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-224.cisco.com [10.21.96.224]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL45112; Mon, 1 Nov 2004 12:35:47 -0800 (PST) Message-ID: <41869E22.7090401@cisco.com> Date: Mon, 01 Nov 2004 15:35:46 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <4185B95C.3050105@cs.columbia.edu> In-Reply-To: <4185B95C.3050105@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> Ultimately, two services are different if their service URIs are >> different, and the same if they rae the same, based on the definition >> of a service as being something you invoke in the network by hitting a >> URI. Thus, adding another index provides two ways of saying the same >> thing, and the resulting possibility of conflicting or confusing results. > > > I think we still disagree here. I think your definition of a URI is too > simplistic. We don't have to go into SIP land to see this: content > negotiation in HTTP can allow two very different documents, in different > languages, for example, to share the same URI. > > See http://httpd.apache.org/docs/content-negotiation.html for a > description on how a popular web server handles this, indicating that > this is more than theoretical. > > To state it briefly: I have no problem with having a particular > composition policy would use URI identity as a means of merging. My > problem is with having the data model rule out composition policies that > deliver multiple service tuples with the same URI. Perhaps I've missed it through the long chains of emails, but you can concisely state what is it you want that to mean? The two suggested so far were (1) different views of the same service from different sources which could not be reconciled by the compositor, and so are presented to the watcher for reconciliation, and (2) or-of-and kind of capability declarations. My view on (2), which I've stated in a previous response, is that you are better off just removing cpabilities which conflict between different services used as input to composition. -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 Nov 1 17:23: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 RAA13096; Mon, 1 Nov 2004 17:23:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkpL-0006Xr-Kq; Mon, 01 Nov 2004 17:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COk9i-0006Es-9u; Mon, 01 Nov 2004 16:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COjiA-0001rF-L8 for simple@megatron.ietf.org; Mon, 01 Nov 2004 16: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 QAA05768 for ; Mon, 1 Nov 2004 16:27:33 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COjx6-0004WZ-5P for simple@ietf.org; Mon, 01 Nov 2004 16:43:03 -0500 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA1LRNMd025815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2004 16:27:24 -0500 (EST) Message-ID: <4186AA36.1000008@cs.columbia.edu> Date: Mon, 01 Nov 2004 16:27:18 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Boehmer Bernhard ICM Berlin Subject: Re: AW: [Simple] Data model - attempt at summary References: <445C57B81208C24EAD99F2944DBB9D2908FE3969@blnss10a.bln1.siemens.de> In-Reply-To: <445C57B81208C24EAD99F2944DBB9D2908FE3969@blnss10a.bln1.siemens.de> 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.11.1.2 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit > - service identification is not yet resolved if haven't missed > something. There seems to be some convergence in the group regarding > URI as a basis but I think there are some issues here; > see also the draft > http://www.ietf.org/internet-drafts/draft-boehmer-simple-service-identification-00.txt > for a discussion of them. This is helpful description, although I have some doubts that adding a level of indirection is necessarily the way to resolve the problem. But that's a discussion for another day. > - You once brought up the question of device identification. > Probably I missed here something but I had the impression > that it remains an open issue. I think that having all device components that report device information agree on a common, shared identifier is going to be painful and error-prone in practice. It seems more likely that they can agree on a small set of unique identifiers. Either way, this is largely speculation since we don't know yet whether we'll have devices publish their own data or whether various pieces of software also publish device information, which is then processed, merged, filtered and published. It would be helpful, if only for my web notes, if somebody could summarize as to why they believe that a single identifier is likely to work in the multiple-publisher case. One possible compromise is to have a primary identifier that has the rule of an element identifier, but allow additional matching identifiers that the composer may use to do merging. > > Another feature which, however, could be deferred is the question > of internal service states as presence information (this relies to > the fifth bullet in your web page). In the abovemetioned draft I > touched a bit upon that but there is no clear answer on that in the > moment. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 17:26: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 RAA13275; Mon, 1 Nov 2004 17:26:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkrk-0006cf-Po; Mon, 01 Nov 2004 17:41:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COk9r-0006Z1-8G; Mon, 01 Nov 2004 16:56:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COjoN-00037P-V7 for simple@megatron.ietf.org; Mon, 01 Nov 2004 16:34:00 -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 QAA06322 for ; Mon, 1 Nov 2004 16:33:58 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COk3L-0004cz-RO for simple@ietf.org; Mon, 01 Nov 2004 16:49:29 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA1LW33i026650 for ; Mon, 1 Nov 2004 16:32:03 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA1LTo3i023600 for ; Mon, 1 Nov 2004 16:30:40 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Data model - attempt at summary (Groups) Date: Mon, 1 Nov 2004 16:31:17 -0500 Message-ID: <8CA1128D59AD27429985B397118CEDDF031B0C87@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Data model - attempt at summary (Groups) Thread-Index: AcS/x9syozriX6guS2qt0bhHfFxz2gAkahNw From: "Boyer, David G \(Dave\)" To: "Henning Schulzrinne" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Henning - Point well taken! Corporations can be treated in a legal sense like a "person" - needs to follow the same rules. In our case a group, just like a person, can respond to INVITEs, respond to subscriptions, send notifications, etc. Dave > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of Henning Schulzrinne > Sent: Sunday, October 31, 2004 10:56 PM > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] Data model - attempt at summary (Groups) >=20 >=20 > Jonathan Rosenberg wrote: >=20 > > I'm not sure if you are proposing rather that we change the name to=20 > > ; that is sufficiently vague to make it not clear=20 > what we are=20 > > trying to model. We are trying to model states of a single person=20 > > relevant for communications. Thus, is the right thing. >=20 > I think is close enough. To use an analogy: I'm not=20 > a lawyer,=20 > but I believe that US law treats corporations consisting of many=20 > individuals in many ways like a person. From a random web page: >=20 > "A legal person is an entity that has the legal capacity to represent=20 > its own interests in its own name, before a court of law, to obtain=20 > rights or obligations for itself, to impose binding=20 > obligations, or to=20 > grant privileges to others, for example as a plaintiff or as a=20 > defendant. A legal person exists wherever the law recognizes, as a=20 > matter of policy, the personality of any entity, regardless=20 > of whether=20 > it is naturally considered to be a person. Thus, a legal person is=20 > distinguished from a natural person. >=20 > In the case of artificial persons, such as corporations for=20 > example, the=20 > "personality" of the legal person, including its rights,=20 > obligations and=20 > actions, is separate from any of the natural persons who=20 > participate in=20 > it, and is not altered by a change in their membership.=20 > Therefore, the=20 > natural persons who are members cannot be held fully=20 > accountable for the=20 > actions of the legal person." >=20 > See also http://en.wikipedia.org/wiki/Legal_person >=20 > Thus, we're really trying to represent a "legal person", not=20 > a "natural=20 > person" here. Since this is good enough for lawyers, this=20 > should be good=20 > enough for a protocol document. I won't point out that the Wikipedia=20 > article uses the term "legal entity", but will note that=20 > "entity" is one=20 > of these words like "node", "stream", "session" that has=20 > enough meanings=20 > without us adding one more. >=20 > Henning >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 17:26:31 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 RAA13354; Mon, 1 Nov 2004 17:26:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COksE-0006dO-4h; Mon, 01 Nov 2004 17:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COk9t-0006c1-Bo; Mon, 01 Nov 2004 16:56:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COjox-00038g-Np for simple@megatron.ietf.org; Mon, 01 Nov 2004 16:34: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 PAA29002 for ; Mon, 1 Nov 2004 15:47:46 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COjKd-0002bD-7N for simple@ietf.org; Mon, 01 Nov 2004 16:03:16 -0500 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA1KlfMd023667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Nov 2004 15:47:42 -0500 (EST) Message-ID: <4186A0E8.3010203@cs.columbia.edu> Date: Mon, 01 Nov 2004 15:47:36 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <4185B95C.3050105@cs.columbia.edu> <41869E22.7090401@cisco.com> In-Reply-To: <41869E22.7090401@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.11.1.2 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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit > > Perhaps I've missed it through the long chains of emails, but you can > concisely state what is it you want that to mean? The two suggested so > far were (1) different views of the same service from different sources > which could not be reconciled by the compositor, and so are presented to > the watcher for reconciliation, and (2) or-of-and kind of capability > declarations. Multiple components of the service whose capabilities cannot be represented by a simple merger without loss of information. > > My view on (2), which I've stated in a previous response, is that you > are better off just removing cpabilities which conflict between > different services used as input to composition. Not sure if I understand the proposal correctly, but are you suggesting that if one publishing entity for the AOR has text capabilities and the other doesn't, that the single service tuple not advertise text at all? In that case, what would happen with two tuples with the same AOR? (1) If the watcher supports caller prefs (or the equivalent for other URIs, as in my example of content-negotiation for HTTP), it can pick the service capability combination that actually exists. (2) If the watcher does not support caller prefs (but understands capabilities), it can do the merging, but know that it might not be able to steer the call, so the result may or may not be optimal. Having one tuple makes this no more or less likely. (3) If the watcher doesn't support callerprefs nor understands capabilities in presence, it just sees two tuples that look the same in the parts that it cares about and merges them. No harm done. Since the compositor cannot know whether the watcher is in category (1), (2) or (3), it seems inappropriate for the compositor to rule out capable watchers, particularly since not-so-bright watchers are no worse of with the extra information. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 1 23:20:52 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 XAA22949; Mon, 1 Nov 2004 23:20:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COqPB-0006RA-UA; Mon, 01 Nov 2004 23:36:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COq0e-00010O-JX; Mon, 01 Nov 2004 23:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COpwL-0006RN-WC for simple@megatron.ietf.org; Mon, 01 Nov 2004 23:06:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22266 for ; Mon, 1 Nov 2004 23:06:34 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COqBM-0006DG-FM for simple@ietf.org; Mon, 01 Nov 2004 23:22:08 -0500 Received: from razor.cs.columbia.edu (IDENT:kagDJT3pPyriUq7p2b2q0PO+9OwENQi4@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA245NRX015037; Mon, 1 Nov 2004 23:05:23 -0500 (EST) Received: from [127.0.0.1] (IDENT:BgVWB1mT3iMJencwRG3RkXufB4bukDct@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA245CXH021637; Mon, 1 Nov 2004 23:05:22 -0500 Message-ID: <41870784.60604@cs.columbia.edu> Date: Mon, 01 Nov 2004 23:05:24 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <1098274146.18584.58.camel@hed039-183.research.nokia.com> <41774342.4020008@dynamicsoft.com> <1098709034.5794.55.camel@hed039-183.research.nokia.com> <417D7C0B.9020806@cisco.com> <1098789320.15902.192.camel@hed039-183.research.nokia.com> <417E65A3.6080802@cisco.com> <4185A94B.4080303@cs.columbia.edu> <4186833E.3070108@cisco.com> In-Reply-To: <4186833E.3070108@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.11.1.6 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > to come back to that. But we don't solve the problem by pretending there > is no difference between alternative and simultaneous capabilities. I wouldn't want to ignore that distinction, but we'd have to separate two different issues: (1) Alternative capabilities that are caused by having multiple contacts (devices, software, etc.), where you get bundles of capabilities that you cannot combine in one session. ("Software 1 does A+V, Software 2 does T"). (2) Alternative capabilities that are caused by the capability constraints of a single device or software, e.g., due to CPU or software limitation ("no, you can't do high-rate video and AAC audio together"). We may be able to solve (2), but we can, in particular, solve (1) [the more common case, in my opinion] fairly easily if we don't get in the way. > Diverse UAs hiding behind a common address (the AOR) is a problem. The > general solution to this is "don't do it". That defeats the whole point of having AORs. > > Publishing this as two tuples with the same AOR isn't better than > merging them as one. Long ago you spelled out the trick to merging these > - say nothing about those features where there is ambiguity. > > In principle, if they are published as separate tuples, then a watcher > could reach the right one by both using the address and including > explicit callerprefs to select the features desired among those > advertised. But We have agreed it is unreasonable to expect watchers to > do that. There is a subtle point here that seems to keep getting lost: I agree that we cannot *expect* a watcher to do this. I want to *allow* a watcher with that capability to do this. You and Jonathan, if I understand you correctly, don't want to allow me to build a system that leverages this capability. As I tried to point out, by giving information to the watcher, a dumb watcher can easily do exactly the same operation that you'd like to force the composer to always do. > > Here is an example of this case: > > - UA1 supports simultaneous voice and video, no IM. > - UA2 supports simultaneous voice and IM, no video. > - Both are registered with AOR of sip:alice@atlanta.com. > - Both publish presence with their capabilities, using > only their AOR as the address. > - Bob is a watcher of Alice. > - Assume Bob receives two tuples for alice, as above. > - Bob wants a videophone call with Alice, so he selects > the voice+video tuple from his videophone and selects > "call". > - The phone sends an invite with offers for voice and > video to Alice's AOR. > - The invite is forked to UA1 and UA2. Both find it > acceptable and ring. > - Alice happens to answer UA2. > - Bob ends up with a voice-only call. > > You fix this in a few ways: > - You insist that distinct addresses be used > - You require every call to include callerprefs for every > capability it may want to use. > > I thought we had agreed that distinct addresses must be used in this > case - I just don't think it is reasonable to expect that callers will > insert the callerprefs, or that proxies will necessarily honor them. As I've tried to point out, the "caller is clueless" case is harmless. The same thing happens as if you'd just published a merged document. In many interesting cases, the PA and proxy know each other (they are part of the same setup, even if they are not the same piece of software). Thus, the publisher can know that this works - or not do it if it doesn't and if it cares to give the caller a choice rather than a "you might get one of these capability sets, but you don't get to decide which one". > > This does however put us between a rock and a hard place if UAs do this, > even though it is wrong. Putting both tuples into the final document > isn't an accurate representation of the situation, nor is having the > most recent one override the older one. The only accurate composition > policy is to merge them, deleting conflicting attributes, but that isn't > especially satisfying either. With the simple composition of addition, none of this is necessary. No information is lost and the watcher can do exactly what the composer would have done, except not having to guess what information was there before it had to be ditched by an forced composition policy along the way. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 2 02: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 CAA22978; Tue, 2 Nov 2004 02:49:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtf5-0002YF-OI; Tue, 02 Nov 2004 03:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtO8-0000PL-JO; Tue, 02 Nov 2004 02:47:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtGj-0005g0-5y for simple@megatron.ietf.org; Tue, 02 Nov 2004 02: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 CAA22494 for ; Tue, 2 Nov 2004 02:39:52 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtVn-0002MM-8s for simple@ietf.org; Tue, 02 Nov 2004 02:55:27 -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 iA27dal25962; Tue, 2 Nov 2004 09:39:36 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 09:39:27 +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 iA27dRNh017501; Tue, 2 Nov 2004 09:39:27 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00BMoazz; Tue, 02 Nov 2004 09:39:25 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA27dMa20543; Tue, 2 Nov 2004 09:39:22 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 09:39:21 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 09:39:19 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.37.172 172.21.37.172 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.noe.nokia.com; 02 Nov 2004 09:39:03 +0200 Subject: Re: [Simple] presence data model: URI as an index From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <4186833E.3070108@cisco.com> References: <4175CCAE.5040508@dynamicsoft.com> <1098274146.18584.58.camel@hed039-183.research.nokia.com> <41774342.4020008@dynamicsoft.com> <1098709034.5794.55.camel@hed039-183.research.nokia.com> <417D7C0B.9020806@cisco.com> <1098789320.15902.192.camel@hed039-183.research.nokia.com> <417E65A3.6080802@cisco.com> <4185A94B.4080303@cs.columbia.edu> <4186833E.3070108@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1099381143.15511.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Tue, 02 Nov 2004 09:39:03 +0200 X-OriginalArrivalTime: 02 Nov 2004 07:39:19.0760 (UTC) FILETIME=[103F2500:01C4C0AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: ext Jonathan Rosenberg , SIMPLE WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit On Mon, 2004-11-01 at 20:41, ext Paul Kyzivat wrote: > Diverse UAs hiding behind a common address (the AOR) is a problem. The > general solution to this is "don't do it". Don't agree. > Publishing this as two tuples with the same AOR isn't better than > merging them as one. Long ago you spelled out the trick to merging these > - say nothing about those features where there is ambiguity. It is immensely better if you think of this in terms of availability and willingness to communicate (the tuples have different basic status and extension statuses, possibly vendor specific ones) instead of in terms of support of features (as in callee capabilities). > In principle, if they are published as separate tuples, then a watcher > could reach the right one by both using the address and including > explicit callerprefs to select the features desired among those > advertised. But We have agreed it is unreasonable to expect watchers to > do that. > > Here is an example of this case: > > - UA1 supports simultaneous voice and video, no IM. > - UA2 supports simultaneous voice and IM, no video. > - Both are registered with AOR of sip:alice@atlanta.com. > - Both publish presence with their capabilities, using > only their AOR as the address. > - Bob is a watcher of Alice. > - Assume Bob receives two tuples for alice, as above. > - Bob wants a videophone call with Alice, so he selects > the voice+video tuple from his videophone and selects > "call". > - The phone sends an invite with offers for voice and > video to Alice's AOR. > - The invite is forked to UA1 and UA2. Both find it > acceptable and ring. > - Alice happens to answer UA2. > - Bob ends up with a voice-only call. > > You fix this in a few ways: > - You insist that distinct addresses be used > - You require every call to include callerprefs for every > capability it may want to use. Well, what you describe above is a feature, not a bug, so my suggestion is not to "fix" it. I think what you're describing is if anything, a bug in offer-answer if it doesn't allow an offerer to explicitly state what medias it *requires* for the call setup to be successful. Having said that though, you *could* implement your presence system using GRUUs to get the above behavior, and that's completely all right. But it isn't all right to mandate that as the one and *only* behavior. > I thought we had agreed that distinct addresses must be used in this > case - I just don't think it is reasonable to expect that callers will > insert the callerprefs, or that proxies will necessarily honor them. I've never agreed with mandating this, although I've always thought that it is a reasonable alternative. > This does however put us between a rock and a hard place if UAs do this, > even though it is wrong. Putting both tuples into the final document > isn't an accurate representation of the situation, nor is having the > most recent one override the older one. The only accurate composition > policy is to merge them, deleting conflicting attributes, but that isn't > especially satisfying either. How about the element? If there is conflicting information, some of which may not even be understood by the composer, putting both tuples into the final document is the only accurate representation. Cheers, Aki > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 2 09:32: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 JAA24347; Tue, 2 Nov 2004 09:32:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COzwz-0002ta-NL; Tue, 02 Nov 2004 09:47:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzYJ-00063j-9k; Tue, 02 Nov 2004 09:22:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzWl-0004zJ-RZ for simple@megatron.ietf.org; Tue, 02 Nov 2004 09:20: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 JAA23485 for ; Tue, 2 Nov 2004 09:20:50 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COzlt-0002fa-FF for simple@ietf.org; Tue, 02 Nov 2004 09:36:30 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 02 Nov 2004 06:20:35 -0800 X-BrightmailFiltered: true 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 iA2EJtnC024809 for ; Tue, 2 Nov 2004 06:19:56 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-142.cisco.com [10.21.96.142]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL89056; Tue, 2 Nov 2004 06:20:17 -0800 (PST) Message-ID: <418797A0.1000604@cisco.com> Date: Tue, 02 Nov 2004 09:20:16 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: multipart/mixed; boundary="------------090703080805030005070306" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Simple] [Fwd: [Sip] IPR disclosure on MESSAGE and related use of SIP] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d This is a multi-part message in MIME format. --------------090703080805030005070306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In case folks have not seen this. -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 --------------090703080805030005070306 Content-Type: message/rfc822; name="[Sip] IPR disclosure on MESSAGE and related use of SIP" Content-Disposition: inline; filename="[Sip] IPR disclosure on MESSAGE and related use of SIP" Return-Path: Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL69927; Mon, 1 Nov 2004 18:16:52 -0800 (PST) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Nov 2004 21:16:52 -0500 X-BrightmailFiltered: true Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA22EavZ000623; Mon, 1 Nov 2004 21:16:48 -0500 (EST) Received: from mail4.dynamicsoft.com (63.110.3.100) by sj-inbound-e.cisco.com with ESMTP; 01 Nov 2004 18:16:45 -0800 X-BrightmailFiltered: true X-Ironport-AV: i="3.86,113,1096873200"; d="scan'208"; a="10170746:sNHT30593900" Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id iA22GiVs005455; Mon, 1 Nov 2004 20:16:44 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Nov 2004 20:16:44 -0600 Received: from proofpoint-01.dynamicsoft.com ([63.113.45.180]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VCHR2S34; Mon, 1 Nov 2004 21:16:34 -0500 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by proofpoint-01.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id iA22Fv10017964; Mon, 1 Nov 2004 21:16:13 -0500 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id iA22FUbq013649; Mon, 1 Nov 2004 21:15:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnq3-0008Gv-Fh; Mon, 01 Nov 2004 20:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnVy-0000St-GS for sip@megatron.ietf.org; Mon, 01 Nov 2004 20:31:14 -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 UAA00577 for ; Mon, 1 Nov 2004 20:31:11 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnkx-00031s-Cl for sip@ietf.org; Mon, 01 Nov 2004 20:46:44 -0500 Received: from [10.89.20.16] ([12.5.186.26]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iA21VSH4029019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Nov 2004 19:31:29 -0600 Message-ID: <4186E354.1040701@softarmor.com> Date: Mon, 01 Nov 2004 19:31:00 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] IPR disclosure on MESSAGE and related use of SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Proofpoint-Spam-Score: 0 X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 Content-Transfer-Encoding: 7bit I've just noticed that Nortel has recently been issued a patent for which they have made an IPR disclosure relative to RFC 3428, the SIP MESSAGE method. The disclosure document is listed at: http://www.ietf.org/ietf/IPR/nortel-ipr-rfc-3428.txt The issued patent is US patent number 6,757,732 and you can retrieve its full text from: http://patft.uspto.gov/netahtml/srchnum.htm -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------090703080805030005070306 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 --------------090703080805030005070306-- From simple-bounces@ietf.org Tue Nov 2 11: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 LAA04352; Tue, 2 Nov 2004 11:04:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1Od-0005B1-V2; Tue, 02 Nov 2004 11:20:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0wD-0007Io-Ok; Tue, 02 Nov 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 1CP0ot-0002Kg-2E for simple@megatron.ietf.org; Tue, 02 Nov 2004 10:43: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 KAA02408 for ; Tue, 2 Nov 2004 10:43:37 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP141-0004eg-9y for simple@ietf.org; Tue, 02 Nov 2004 10:59:17 -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 iA2FhYe17676; Tue, 2 Nov 2004 17:43:35 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 17:43:30 +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 iA2FhUMd027290; Tue, 2 Nov 2004 17:43:30 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00S1faNn; Tue, 02 Nov 2004 17:43:28 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 iA2FhRa00603; Tue, 2 Nov 2004 17:43:28 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 17:43:20 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 17:43:18 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt Date: Tue, 2 Nov 2004 17:43:18 +0200 Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt Thread-Index: AcTAJnJnxlL4UlSuQZOdn3Ed7Mu+8wArih7Q To: X-OriginalArrivalTime: 02 Nov 2004 15:43:18.0996 (UTC) FILETIME=[ACFAE940:01C4C0F2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Hi, > mikko.lonnfors@nokia.com wrote: > >=20 > > Jumping to other topic.=20 > > Prescaps now defines and elements that > > belong to documents. I think these elements provide > > useful information but I think that their place is not exactly > > in the prescaps I-D. >=20 > I agree that these aren't "capabilities". > OTOH, these are things that are part of RFC 3840 (callee caps). > A case can be made that prescaps is the place to define how=20 > everything=20 > in 3840 maps to presence. Yes and this is now causing this issue. and are = already being defined in document. Now, if we have same = similar information also in mapping to callee caps becomes bit = ubiquitous. What I had in mind was that call caps description and = priority would map to and elements of devcaps = document. I also though that priority and description might make sense = in devcaps but those would not have any mapping to callee caps. For this = reason I though it might make sense to move these elements to somewhere = else. - Mikko > > It might make more sense to move them for example to presence > > data model (include them into=20 > urn:ietf:params:xml:ns:pidf:device schema). > > What do you think? >=20 > It doesn't matter much to me where the data elements are defined, as=20 > long as they are defined somewhere. I don't know if the data=20 > model is a=20 > very good place - it mainly defines a framework rather than=20 > the detailed=20 > contents. If not prescaps, then I would think rpid would be the other=20 > likely place, or else yet another independent draft. >=20 > But if these are not defined in prescaps, then I think it=20 > would be good=20 > for prescaps to cross reference where they are defined. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 2 13:18:21 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 NAA23872; Tue, 2 Nov 2004 13:18:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3To-0001CD-9A; Tue, 02 Nov 2004 13:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2vA-0001yZ-Qv; Tue, 02 Nov 2004 12:58:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2iv-0003YG-IB for simple@megatron.ietf.org; Tue, 02 Nov 2004 12:45: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 MAA16549 for ; Tue, 2 Nov 2004 12:45:32 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2xz-0008GJ-Nw for simple@ietf.org; Tue, 02 Nov 2004 13:01:15 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iA2HjUBO022611 for ; Tue, 2 Nov 2004 18:45:30 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iA2HjTBO017669 for ; Tue, 2 Nov 2004 18:45:29 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR9QR9>; Tue, 2 Nov 2004 18:45:29 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F05319E18@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: SIMPLE WG Date: Tue, 2 Nov 2004 18:45:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Simple] Draft on 'Service Identification' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 hi all, we have written a draft on 'Service Identification'. you can find it at: http://www.ietf.org/internet-drafts/draft-boehmer-simple-service-identificat ion-00.txt Abstract This document discusses the aspect of service identification in presence documents. A solution is proposed which extends RPID by utilizing the tModel service description provided by the Universal Description, Discovery and Integration (UDDI) framework. ciao hannes _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 2 19:29: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 TAA05992; Tue, 2 Nov 2004 19:29:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9HT-0003SM-Qe; Tue, 02 Nov 2004 19:45:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8ge-0007eI-Bv; Tue, 02 Nov 2004 19:07:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8WH-0001rl-4L for simple@megatron.ietf.org; Tue, 02 Nov 2004 18:56: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 SAA02519 for ; Tue, 2 Nov 2004 18:56:54 -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 1CP8lS-0002Pv-Se for simple@ietf.org; Tue, 02 Nov 2004 19:12:40 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 Nov 2004 16:08:56 -0800 X-BrightmailFiltered: true 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 iA2NuKcp013926; Tue, 2 Nov 2004 15:56:21 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMT20536; Tue, 2 Nov 2004 18:56:19 -0500 (EST) Message-ID: <41881EA3.5090604@cisco.com> Date: Tue, 02 Nov 2004 18:56:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Mikko, Maybe I misunderstood you. Even though the prescaps stuff is now split between a element and a element, aren't both of those being defined in the same prescaps-ext I-D? I only meant that I hope this I-D will discuss how all the things in callee-caps map to presence. It doesn't even have to be the authoritative place where all the elements are defined. If it makes sense to have more than one I-D, then it would be fine to simply refer. Paul mikko.lonnfors@nokia.com wrote: > Hi, > > >>mikko.lonnfors@nokia.com wrote: >> >>>Jumping to other topic. >> >> > Prescaps now defines and elements that >> > belong to documents. I think these elements provide >> > useful information but I think that their place is not exactly >> > in the prescaps I-D. >> >>I agree that these aren't "capabilities". >>OTOH, these are things that are part of RFC 3840 (callee caps). >>A case can be made that prescaps is the place to define how >>everything >>in 3840 maps to presence. > > > Yes and this is now causing this issue. and are already being defined in document. Now, if we have same similar information also in mapping to callee caps becomes bit ubiquitous. What I had in mind was that call caps description and priority would map to and elements of devcaps document. I also though that priority and description might make sense in devcaps but those would not have any mapping to callee caps. For this reason I though it might make sense to move these elements to somewhere else. > > - Mikko > > >> > It might make more sense to move them for example to presence >> > data model (include them into >>urn:ietf:params:xml:ns:pidf:device schema). >> > What do you think? >> >>It doesn't matter much to me where the data elements are defined, as >>long as they are defined somewhere. I don't know if the data >>model is a >>very good place - it mainly defines a framework rather than >>the detailed >>contents. If not prescaps, then I would think rpid would be the other >>likely place, or else yet another independent draft. >> >>But if these are not defined in prescaps, then I think it >>would be good >>for prescaps to cross reference where they are defined. >> >> 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 Wed Nov 3 02:54: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 CAA08249; Wed, 3 Nov 2004 02:54:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGDz-0004uA-OP; Wed, 03 Nov 2004 03:10:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFmi-0005KC-Tp; Wed, 03 Nov 2004 02:42:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFgt-0002af-BJ for simple@megatron.ietf.org; Wed, 03 Nov 2004 02:36:23 -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 CAA07036 for ; Wed, 3 Nov 2004 02:36:21 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPFwA-0004Wm-BR for simple@ietf.org; Wed, 03 Nov 2004 02:52:10 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 Nov 2004 23:36:27 -0800 X-BrightmailFiltered: true 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 iA37a9JZ008076; Tue, 2 Nov 2004 23:36:09 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-358.cisco.com [10.21.97.102]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFM46952; Tue, 2 Nov 2004 23:36:08 -0800 (PST) Message-ID: <41888A67.6040807@cisco.com> Date: Wed, 03 Nov 2004 02:36:07 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Authorization Rules Discussion A: Sphere Interpretation References: <5816828233DEFA41807A6CFDFDF2343C3A8BD0@esebe056.ntc.nokia.com> In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8BD0@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, pkyzivat@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > I also assumed that composition is watcher specific, but something in > this discussion has confused me. > > If I publish 2 views of my presence, one for co-workers and another > for friends. > > In sphere "work-mode" : I am "in-a-meeting" > > In sphere "play-mode": I am "busy" > > I want my co-workers to see my person presence with sphere > "work-mode" and my friends to see my person presence with sphere > "play-mode". > > Now, if the composition takes place before the authorisation policy, > then I am no longer able to do that. The composition policy might > merge these 2 to be sphere "play-mode". Well, it wouldn't. Thats the point. Here is a classic case where you want to have watcher specific composition policies. So, in this case, you'd have a policy that is something like this: for watchers that are my friends { keep the person tuple whose is "play-mode" } else for watchers that are co-workers { keep the person tuple whose is "work-mode" } This would result in a different document, post composition, depending on who the watcher is. > > If I have a rule for a co-worker, Aki, that says only show him > presence info with sphere "work-mode", then Aki will not get any > presence info of mine as a person. Is the right? No. The composition would first make sure that the right information is selected for the watcher. If you have privacy permissions which prevent information from being sent if the is not "work-mode", those would serve as an additional check. However, for the example composiiton algorithm, it would not remove any further information. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 03:09: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 DAA09253; Wed, 3 Nov 2004 03:09:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGSW-0005CW-Bw; Wed, 03 Nov 2004 03:25:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPG0s-0003Ft-2J; Wed, 03 Nov 2004 02:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFuV-0008Lh-Ev for simple@megatron.ietf.org; Wed, 03 Nov 2004 02:50: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 CAA08067 for ; Wed, 3 Nov 2004 02:50:25 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPG9m-0004ot-LI for simple@ietf.org; Wed, 03 Nov 2004 03:06:15 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 Nov 2004 23:50:11 -0800 X-BrightmailFiltered: true 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 iA37nrJZ009948; Tue, 2 Nov 2004 23:49:53 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-358.cisco.com [10.21.97.102]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFM47280; Tue, 2 Nov 2004 23:49:52 -0800 (PST) Message-ID: <41888DA0.3060607@cisco.com> Date: Wed, 03 Nov 2004 02:49:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: krisztian.kiss@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: pres-rules: extensibility X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit inline. krisztian.kiss@nokia.com wrote: > Hi, > > The I-D says about extensibility: > > 6. Schema Extensibility > > It is anticipated that future changes to this specification are > accomplished through extensions that define new types of permissions. > These extensions MUST exist within a different namespace. > Furthermore, the schema defined above and the namespace for elements > defined within it MUST NOT be altered by future specifications. > Changes in the basic schema, or in the interpretation of elements > within that schema, may result in violations of user privacy due to > mis-interpretation of documents. > > If someone extends the schema defined in the draft in a new > namespace, the result could be a new authorization document with > different semantics. Different, in the sense that it adds new permissions - yes. different, in that it changes the meaning of existing permissions - no. > So, when applying the extended authorization > document on a raw presence document, authorization decisions are > probably different as when applying the same authorization document > restricted to the "original" namespace. The question is whether it is > still makes sense to store the extended document under AUID > "pres-rules" (or one should reserve a new AUID?), as Presence Servers > understanding only the schema defined in > draft-ietf-simple-presence-rules-01 (and ignoring the extensions) > could make incorrect decisions. I think they should all use pres-rules. I don't see what the problem is with doing that, or what changes if they are placed under a different auid. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 03:10: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 DAA09377; Wed, 3 Nov 2004 03:10:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGTB-0005E6-Nt; Wed, 03 Nov 2004 03:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPG0s-0003GS-RW; Wed, 03 Nov 2004 02:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFul-0008Ly-K9 for simple@megatron.ietf.org; Wed, 03 Nov 2004 02:50: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 CAA08072 for ; Wed, 3 Nov 2004 02:50:42 -0500 (EST) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGA2-0004p3-Dm for simple@ietf.org; Wed, 03 Nov 2004 03:06:31 -0500 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id iA37nrdr003543; Wed, 3 Nov 2004 08:49:54 +0100 (MET) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id iA37nmDm011605; Wed, 3 Nov 2004 08:49:48 +0100 (MET) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Nov 2004 08:49:48 +0100 Message-ID: <445C57B81208C24EAD99F2944DBB9D2908FE39CE@blnss10a.bln1.siemens.de> From: Boehmer Bernhard ICM Berlin To: "'Henning Schulzrinne'" , Boehmer Bernhard ICM Berlin Subject: AW: AW: [Simple] Data model - attempt at summary Date: Wed, 3 Nov 2004 08:49:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Hi Henning, service ID: certainly indirection has its drawbacks; in this case the main question is whether the higher flexibility of indirection outweighs the overhead introduced with that. Actually, the whole XML schema architecture is using it heavily (this becomes obvious to me each time I edit XML schemas without being connected to the Internet...:). deviceID: I agree that, for the IETF, it is more complicated to solve this issue. For the Open Mobile Alliance, I think, it is simpler. I issued there a proposal where it is simply mandated that the device MUST generate a unique ID based on the UUID URN algorithm. The IETF doesn't have this "comprehensive" approach to standardization and must rely on the fact that=20 the device OSs will provide such unique identifiers. Regards Bernhard > -----Urspr=FCngliche Nachricht----- > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Montag, 1. November 2004 22:27 > An: Boehmer Bernhard ICM Berlin > Cc: Simple WG > Betreff: Re: AW: [Simple] Data model - attempt at summary >=20 >=20 > > - service identification is not yet resolved if haven't missed > > something. There seems to be some convergence in the=20 > group regarding=20 > > URI as a basis but I think there are some issues here; > > see also the draft=20 > >=20 > http://www.ietf.org/internet-drafts/draft-boehmer-simple-servi ce-identification-00.txt > for a discussion of them.=20 This is helpful description, although I have some doubts that adding a=20 level of indirection is necessarily the way to resolve the problem. But = that's a discussion for another day. > - You once brought up the question of device identification.=20 > Probably I missed here something but I had the impression > that it remains an open issue. I think that having all device components that report device = information=20 agree on a common, shared identifier is going to be painful and=20 error-prone in practice. It seems more likely that they can agree on a=20 small set of unique identifiers. Either way, this is largely = speculation=20 since we don't know yet whether we'll have devices publish their own=20 data or whether various pieces of software also publish device=20 information, which is then processed, merged, filtered and published. It would be helpful, if only for my web notes, if somebody could=20 summarize as to why they believe that a single identifier is likely to=20 work in the multiple-publisher case. One possible compromise is to have = a primary identifier that has the rule of an element identifier, but=20 allow additional matching identifiers that the composer may use to do=20 merging. >=20 > Another feature which, however, could be deferred is the question > of internal service states as presence information (this relies to > the fifth bullet in your web page). In the abovemetioned draft I > touched a bit upon that but there is no clear answer on that in the > moment.=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 03:11: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 DAA09500; Wed, 3 Nov 2004 03:11:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGTr-0005Fa-0L; Wed, 03 Nov 2004 03:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPG0u-0003Gr-21; Wed, 03 Nov 2004 02:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFyZ-0001oZ-Oj for simple@megatron.ietf.org; Wed, 03 Nov 2004 02:54: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 CAA08239 for ; Wed, 3 Nov 2004 02:54:38 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGDq-0004tV-2E for simple@ietf.org; Wed, 03 Nov 2004 03:10:27 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 02 Nov 2004 23:54:22 -0800 X-BrightmailFiltered: true 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 iA37s5om015857; Tue, 2 Nov 2004 23:54:05 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-358.cisco.com [10.21.97.102]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFM47372; Tue, 2 Nov 2004 23:54:03 -0800 (PST) Message-ID: <41888E9A.6030701@cisco.com> Date: Wed, 03 Nov 2004 02:54:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: krisztian.kiss@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: [Simple] Re: pres-rules/common-pol: splitting and X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit inline. krisztian.kiss@nokia.com wrote: > Hi, > > pres-rules/common-pol combines and under > . There is a concern that this might be inefficient as > need to be evaluated after every composition attempt, even > if for active subscriptions. The question is whether splitting of the > authorization document to two documents (one is like subscription > authorization rules including the , the second is like > content rules including the ) would make any > sense... The data model addresses this. It says that the authorization document will contain information that is applicable only to subscription processing (sub-handling in particular) and other information specific to privacy filtering. I'll make sure that the presence rules document clearly spells out where each element is applicable. 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 Wed Nov 3 03:19: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 DAA10158; Wed, 3 Nov 2004 03:19:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGc3-0005T8-Jm; Wed, 03 Nov 2004 03:35:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPGKm-0003Ab-MQ; Wed, 03 Nov 2004 03:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPGI5-0001qq-UA for simple@megatron.ietf.org; Wed, 03 Nov 2004 03:14:50 -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 DAA09862 for ; Wed, 3 Nov 2004 03:14:48 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGXN-0005MD-Bj for simple@ietf.org; Wed, 03 Nov 2004 03:30:37 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 03 Nov 2004 00:14:34 -0800 X-BrightmailFiltered: true 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 iA38EFJZ013943; Wed, 3 Nov 2004 00:14:16 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-358.cisco.com [10.21.97.102]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFM47895; Wed, 3 Nov 2004 00:13:46 -0800 (PST) Message-ID: <41889339.7010206@cisco.com> Date: Wed, 03 Nov 2004 03:13:45 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Presence Authorization Discussion - subscriber dependent composition? References: <5816828233DEFA41807A6CFDFDF2343C3A8BE8@esebe056.ntc.nokia.com> <41865815.5050900@cisco.com> In-Reply-To: <41865815.5050900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > (Changed to subject to be more specific) > > I had a discussion with Jonathan about this, and I am coming to agree > that letting composition policy be subscriber dependent is probably the > right course for us. > > I had two objections to this: > - efficiency > - complexity of defining composition policy > > I have now concluded that the efficiency differences between the two > approaches are probably negligible in the overall scheme of things - at > least so that it shouldn't be a criterion in the decision. Let me try to address one of Hisham's points specifically. His concern was that if you had composition policy be watcher dependent, then you couldn't store the raw presence document in advance of a subscription; you'd have to re-do composiiton for each watcher. The short answer is, yes, but I don't see the alternative. In the model, composition is where I am able to do things like have totally different versions of my status for different watchers. Polite blocking is in this category. Thus, if we want this capability (and I think we do), then we can't just say "composition should be independent of watcher" - you need to provide an alternative formulation of the model where this functionality resides. The other response I would give is that, in the event where the number of composition policies is limited, you can pre-compute the outputs of all of the possible composition poliices, and thus get the same savings you are looking for. Paul had pointed out to me a problem in the data model. It current envisions composition policy as taking place before filtering and then again afterwards to recombine tuples that may no longer make sense to exist separately after removal of information. However, if the scope of composition policy is the ability to inject static tuples (for example, to support polite blocking), then you can't do this. Any composition policy that occurs after privacy filtering can not ever introduce additional inforamtion into the document, and currently composition can. Thus, this post-privacy composition policy may actually be something else entirely or in part. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 06:19:26 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 GAA24438; Wed, 3 Nov 2004 06:19:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPJQ6-000181-DJ; Wed, 03 Nov 2004 06:35:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPIt6-00028x-5J; Wed, 03 Nov 2004 06:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPI7J-0001wc-OJ for simple@megatron.ietf.org; Wed, 03 Nov 2004 05:11: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 FAA17954 for ; Wed, 3 Nov 2004 05:11:47 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPIMb-00084L-3C for simple@ietf.org; Wed, 03 Nov 2004 05:27:38 -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 iA3ABiE21799; Wed, 3 Nov 2004 12:11:44 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 12:11:49 +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 iA3ABnw1001357; Wed, 3 Nov 2004 12:11:49 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MRjih1; Wed, 03 Nov 2004 12:09:19 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 iA3A8lS29638; Wed, 3 Nov 2004 12:08:47 +0200 (EET) Received: from [172.21.37.239] ([172.21.37.239]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 12:08:46 +0200 Message-ID: <4188AE2E.4060904@nokia.com> Date: Wed, 03 Nov 2004 12:08:46 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: =?ISO-8859-1?Q?L=F6nnfors_Mikko_Aleksi?= , =?ISO-8859-1?Q?Lepp=E4nen_Eva-Maria?= , Khartabil Hisham , Jari Urpalainen Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2004 10:08:46.0984 (UTC) FILETIME=[1B8AB080:01C4C18D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Orit Levin , SIMPLE mailing list Subject: [Simple] "version" definition in partial PIDF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi: The discussion came in the SIPPING mailing list and is related to the "version" attribute counter that both the conference event package and the partical PIDF have. Currently both drafts indicate in the text that the version info is a 32 bit counter. However, the XML schemas do not have such restriction: Partial PIDF defines it as a nonNegativeInteger and conference event package as a string. I think we should express as many restrictions as possible in the XML schema, so we can reuse standard XML schema validators, and we don't need to encode additional restrictions in the code itself. Therefore, I am suggesting to add a "maxInclusive" facet to the "version" attribute definition, whose value is 2**32 - 1. Please synchronize with Orit, who is editing the conference event package. 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 Wed Nov 3 06: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 GAA25551; Wed, 3 Nov 2004 06:26:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPJWf-0001NJ-5x; Wed, 03 Nov 2004 06:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPJ4X-0007Ec-Lp; Wed, 03 Nov 2004 06:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPIcE-0006F6-17 for simple@megatron.ietf.org; Wed, 03 Nov 2004 05:43: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 FAA20527 for ; Wed, 3 Nov 2004 05:43:43 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPIrW-0000Kj-Lw for simple@ietf.org; Wed, 03 Nov 2004 05:59:35 -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 iA3AheE10059; Wed, 3 Nov 2004 12:43:40 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 12:43:28 +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 iA3AhSRb001355; Wed, 3 Nov 2004 12:43:28 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00mZ9QCQ; Wed, 03 Nov 2004 12:43:20 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 iA3AhKS27033; Wed, 3 Nov 2004 12:43:20 +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, 3 Nov 2004 12:42:44 +0200 Received: from nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id 8F25193B75; Wed, 3 Nov 2004 12:42:43 +0200 (EET) Message-ID: <4188B58E.70809@nokia.com> Date: Wed, 03 Nov 2004 12:40:14 +0200 From: Jari Urpalainen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia References: <4188AE2E.4060904@nokia.com> In-Reply-To: <4188AE2E.4060904@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2004 10:42:44.0890 (UTC) FILETIME=[DA3A77A0:01C4C191] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Orit Levin , =?ISO-8859-1?Q?L=F6nnfors_Mikko_Aleksi?= , =?ISO-8859-1?Q?Lepp=E4nen_Eva-Maria?= , SIMPLE mailing list Subject: [Simple] Re: "version" definition in partial PIDF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > Hi: > > The discussion came in the SIPPING mailing list and is related to the > "version" attribute counter that both the conference event package and > the partical PIDF have. > > Currently both drafts indicate in the text that the version info is a > 32 bit counter. However, the XML schemas do not have such restriction: > Partial PIDF defines it as a nonNegativeInteger and conference event > package as a string. > > I think we should express as many restrictions as possible in the XML > schema, so we can reuse standard XML schema validators, and we don't > need to encode additional restrictions in the code itself. Therefore, > I am suggesting to add a "maxInclusive" facet to the "version" > attribute definition, whose value is 2**32 - 1. > > > > > > > > Please synchronize with Orit, who is editing the conference event > package. > > Regards, > > Miguel Probably unsignedInt datatype is the right answer ;) --Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 07:40: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 HAA03056; Wed, 3 Nov 2004 07:40:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKgi-0003GN-LU; Wed, 03 Nov 2004 07:56:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPKGu-0007eD-B0; Wed, 03 Nov 2004 07:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPK8Z-00064Z-Ne for simple@megatron.ietf.org; Wed, 03 Nov 2004 07:21: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 HAA01128 for ; Wed, 3 Nov 2004 07:21:14 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKNs-0002mo-9B for simple@ietf.org; Wed, 03 Nov 2004 07:37:05 -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 iA3CL9E07575; Wed, 3 Nov 2004 14:21:10 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 14:20:30 +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 iA3CKUHC005959; Wed, 3 Nov 2004 14:20:30 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00NYUIzU; Wed, 03 Nov 2004 14:20:29 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 iA3CKRa28891; Wed, 3 Nov 2004 14:20:28 +0200 (EET) Received: from [172.21.37.239] ([172.21.37.239]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 14:20:27 +0200 Message-ID: <4188CD0B.3080707@nokia.com> Date: Wed, 03 Nov 2004 14:20:27 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] Re: "version" definition in partial PIDF References: <4188AE2E.4060904@nokia.com> <4188B58E.70809@nokia.com> In-Reply-To: <4188B58E.70809@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2004 12:20:27.0496 (UTC) FILETIME=[809D2680:01C4C19F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Orit Levin , "Lonnfors Mikko \(Nokia-NRC/Helsinki\)" , "Leppanen Eva-Maria \(Nokia-NET/Tampere\)" , SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Thanks, Jari. Definitely, unsignedInt is an integer that ranges from 0 unil 2**32 -1, so it will do the same thing. So the proposal then is to define "version" as: BR, Miguel Jari Urpalainen wrote: > Miguel Garcia wrote: > > >>Hi: >> >>The discussion came in the SIPPING mailing list and is related to the >>"version" attribute counter that both the conference event package and >>the partical PIDF have. >> >>Currently both drafts indicate in the text that the version info is a >>32 bit counter. However, the XML schemas do not have such restriction: >>Partial PIDF defines it as a nonNegativeInteger and conference event >>package as a string. >> >>I think we should express as many restrictions as possible in the XML >>schema, so we can reuse standard XML schema validators, and we don't >>need to encode additional restrictions in the code itself. Therefore, >>I am suggesting to add a "maxInclusive" facet to the "version" >>attribute definition, whose value is 2**32 - 1. >> >> >> >> >> >> >> >>Please synchronize with Orit, who is editing the conference event >>package. >> >>Regards, >> >> Miguel > > > Probably unsignedInt datatype is the right answer ;) > --Jari > > _______________________________________________ > 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 Wed Nov 3 08:36: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 IAA08418; Wed, 3 Nov 2004 08:36:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLZ9-0004yt-7D; Wed, 03 Nov 2004 08:52:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPLBo-0005tv-MY; Wed, 03 Nov 2004 08:28:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPL4h-0003yY-Iv for simple@megatron.ietf.org; Wed, 03 Nov 2004 08:21: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 IAA07024 for ; Wed, 3 Nov 2004 08:21:18 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLK0-0004cT-QY for simple@ietf.org; Wed, 03 Nov 2004 08:37:10 -0500 Received: from razor.cs.columbia.edu (IDENT:2FvM73sK/exxkPFEoSgtbrlijB8blAcS@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA3DLDRX013941; Wed, 3 Nov 2004 08:21:13 -0500 (EST) Received: from [127.0.0.1] (IDENT:nQvoXtp/eWww5VNh8DAFpptqmTkGFEyv@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA3DLCXH030495; Wed, 3 Nov 2004 08:21:12 -0500 Message-ID: <4188DB48.4040104@cs.columbia.edu> Date: Wed, 03 Nov 2004 08:21:12 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Boehmer Bernhard ICM Berlin Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: <445C57B81208C24EAD99F2944DBB9D2908FE39CE@blnss10a.bln1.siemens.de> In-Reply-To: <445C57B81208C24EAD99F2944DBB9D2908FE39CE@blnss10a.bln1.siemens.de> 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.11.3.0 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Boehmer Bernhard ICM Berlin wrote: > Hi Henning, > service ID: certainly indirection has its drawbacks; > in this case the main question is whether the higher > flexibility of indirection outweighs the overhead > introduced with that. Actually, the whole XML schema > architecture is using it heavily (this becomes obvious > to me each time I edit XML schemas without being connected > to the Internet...:). While it is easy for a mobile provider to publish a UDDI directory entry for its limited number of phones, say, it seems much harder for the average user in a corporate network or using a provider. They will have to rely on the provider or corporate network to host this information. Unless you want to rely on web pages for configuration, every new source of information means that there needs to be authentication, a means to publish this information and to change it. The only advantage of inclusion by reference is space saving. Otherwise, whatever service description you include by reference can also be included by value. The space saving only matters if the mobile transmits the information. This seems unlikely, even with inclusion. Thus, I'm at a loss to see why adding another protocol machinery for managing UDDI stores to every PUA or PA adds significant value that outweighs the complexity incurred. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 08:57: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 IAA10111; Wed, 3 Nov 2004 08:57:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLt5-0005Tk-Vd; Wed, 03 Nov 2004 09:13:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPLaD-0002XJ-Rv; Wed, 03 Nov 2004 08:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPLWg-0001dA-10 for simple@megatron.ietf.org; Wed, 03 Nov 2004 08:50:14 -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 IAA09321 for ; Wed, 3 Nov 2004 08:50:12 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLlz-0005Hz-Hq for simple@ietf.org; Wed, 03 Nov 2004 09:06:04 -0500 Received: from razor.cs.columbia.edu (IDENT:yb4dJnKT0bDer+CD+6xH6T89Wj72A0CY@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA3Do9RX019446; Wed, 3 Nov 2004 08:50:09 -0500 (EST) Received: from [127.0.0.1] (IDENT:QQdjHhbZos39mcTF1eaPMP8mfXjgIOvp@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA3Do8XH030542; Wed, 3 Nov 2004 08:50:08 -0500 Message-ID: <4188E20F.9080503@cs.columbia.edu> Date: Wed, 03 Nov 2004 08:50:07 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Authorization Rules Discussion A: Sphere Interpretation References: <5816828233DEFA41807A6CFDFDF2343C3A8BD0@esebe056.ntc.nokia.com> <41888A67.6040807@cisco.com> In-Reply-To: <41888A67.6040807@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.11.3.0 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > for watchers that are my friends { > keep the person tuple whose is "play-mode" > } else for watchers that are co-workers { > keep the person tuple whose is "work-mode" > } > As I tried to point out in an earlier message, I think we have a somewhat different understanding of . In my definition, reflects the state of the presentity, just like mood, activity and location. Thus, normally a presentity can only be in one state. Naturally, different sensors may be confused as to the state, just like for the other descriptors, but you wouldn't have "work" tuples and "play" tuples. The privacy rules reflect this, in that is an input determining who gets my data. Instead, the composition rule would be if I'm in sphere = work send elements of class 'foo' to my work buddies if I'm in sphere = play send elements of class 'bar', 'rab' and 'oof' to my play buddies _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 09:33: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 JAA13100; Wed, 3 Nov 2004 09:33:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMRl-0006JK-8D; Wed, 03 Nov 2004 09:49:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPM3b-0008Lj-4C; Wed, 03 Nov 2004 09:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPM0N-0007fG-V0 for simple@megatron.ietf.org; Wed, 03 Nov 2004 09:20: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 JAA12024 for ; Wed, 3 Nov 2004 09:20:54 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMFf-000600-H8 for simple@ietf.org; Wed, 03 Nov 2004 09:36:46 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2004 06:20:49 -0800 X-BrightmailFiltered: true 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 iA3EKIVB015713; Wed, 3 Nov 2004 06:20:19 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-358.cisco.com [10.21.97.102]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFM56872; Wed, 3 Nov 2004 06:20:18 -0800 (PST) Message-ID: <4188E921.2060906@cisco.com> Date: Wed, 03 Nov 2004 09:20:17 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Authorization Rules Discussion A: Sphere Interpretation References: <5816828233DEFA41807A6CFDFDF2343C3A8BD0@esebe056.ntc.nokia.com> <41888A67.6040807@cisco.com> <4188E20F.9080503@cs.columbia.edu> In-Reply-To: <4188E20F.9080503@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> inline. > > >> for watchers that are my friends { >> keep the person tuple whose is "play-mode" >> } else for watchers that are co-workers { >> keep the person tuple whose is "work-mode" >> } >> > > As I tried to point out in an earlier message, I think we have a > somewhat different understanding of . In my definition, > reflects the state of the presentity, just like mood, activity and > location. I understand that. The question that Aki was raising was a scenario in which there are two different person elements published for a user, one with at home, and one at work. The objective was to select one of these two based on composition policies. This case would arise when a user wishes to appear in different spheres to different watchers. > Thus, normally a presentity can only be in one state. Right. Thats why the composition algorithm needs to pick one. > Naturally, different sensors may be confused as to the state, just like > for the other descriptors, but you wouldn't have "work" tuples and > "play" tuples. > > The privacy rules reflect this, in that is an input determining > who gets my data. > > Instead, the composition rule would be > > if I'm in sphere = work > send elements of class 'foo' to my work buddies > if I'm in sphere = play > send elements of class 'bar', 'rab' and 'oof' to my play buddies That wouldn't be a composition rule, it would be a privacy filtering rule. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 14:58: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 OAA13517; Wed, 3 Nov 2004 14:58:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRWN-0005tb-Us; Wed, 03 Nov 2004 15:14:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPREd-0007ma-Qm; Wed, 03 Nov 2004 14:55:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPR8v-00071o-U2 for simple@megatron.ietf.org; Wed, 03 Nov 2004 14:50: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 OAA12930 for ; Wed, 3 Nov 2004 14:50:04 -0500 (EST) Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRO9-0005hO-V6 for simple@ietf.org; Wed, 03 Nov 2004 15:06:00 -0500 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20041103194920.HFBO20100.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net>; Wed, 3 Nov 2004 13:49:20 -0600 Received: from THANOSDIACAKIS3 ([12.25.200.5]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20041103194920.EFAE10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3>; Wed, 3 Nov 2004 13:49:20 -0600 From: "Thanos Diacakis" To: "'Jonathan Rosenberg'" , Subject: RE: [Simple] Re: pres-rules/common-pol: splitting and Date: Wed, 3 Nov 2004 12:49:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBfLUAipa2Ge3uRsiRMLTcrOZuqgAYQK7w In-Reply-To: <41888E9A.6030701@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20041103194920.EFAE10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit So an implementation would need to evaluate the conditions in *every* row, whenever a subscription is received *and* everytime a notification is about to be sent? That doesn't seem like a very efficient way of doing things. I think having those into two tables, would make life easier. If you're trying to decide whether you're authorizing a sub, you look in the one table. Conversely, if you're trying to determine what transformations to apply to send out a notification, you look at the other table. Thanos > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: Wednesday, November 03, 2004 12:54 AM > To: krisztian.kiss@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: [Simple] Re: pres-rules/common-pol: splitting > and > > inline. > > krisztian.kiss@nokia.com wrote: > > > Hi, > > > > pres-rules/common-pol combines and > under > > . There is a concern that this might be inefficient > as > > need to be evaluated after every composition attempt, even if for > > active subscriptions. The question is whether splitting of the > > authorization document to two documents (one is like subscription > > authorization rules including the , the second is like > > content rules including the ) would make > any sense... > > The data model addresses this. It says that the authorization > document will contain information that is applicable only to > subscription processing (sub-handling in particular) and > other information specific to privacy filtering. I'll make > sure that the presence rules document clearly spells out > where each element is applicable. > > 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 3 15:00: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 PAA13777; Wed, 3 Nov 2004 15:00:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRYk-0005xh-Ak; Wed, 03 Nov 2004 15:16:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPREk-0007qw-2H; Wed, 03 Nov 2004 14:56:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRCT-0007FB-EZ for simple@megatron.ietf.org; Wed, 03 Nov 2004 14:53: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 OAA13162 for ; Wed, 3 Nov 2004 14:53:44 -0500 (EST) Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRRr-0005m3-Ik for simple@ietf.org; Wed, 03 Nov 2004 15:09:40 -0500 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20041103195314.HGUG20100.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net>; Wed, 3 Nov 2004 13:53:14 -0600 Received: from THANOSDIACAKIS3 ([12.25.200.5]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20041103195314.EFZN10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3>; Wed, 3 Nov 2004 13:53:14 -0600 From: "Thanos Diacakis" To: "'Jonathan Rosenberg'" , Subject: RE: [Simple] Re: pres-rules: extensibility Date: Wed, 3 Nov 2004 12:53:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBfIhLfE8d4yZTThWJxDVAFGyWRgAYcTiA In-Reply-To: <41888DA0.3060607@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20041103195314.EFZN10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit If any extensions make the authorization rules more restrictive, then an application that doesn't understand the extensions, would not be able to apply them correctly. Using the same AUID would tell the application that the contents of the documents conform to the semantics of "presence-rules", which would clearly not be the case. If a different AUID was used, then the application would have to understand that AUID and what the semantical implications are, due to the utilized extensions. Thanos > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: Wednesday, November 03, 2004 12:50 AM > To: krisztian.kiss@nokia.com > Cc: simple@ietf.org > Subject: [Simple] Re: pres-rules: extensibility > > inline. > > krisztian.kiss@nokia.com wrote: > > > Hi, > > > > The I-D says about extensibility: > > > > 6. Schema Extensibility > > > > It is anticipated that future changes to this specification are > > accomplished through extensions that define new types of > permissions. > > These extensions MUST exist within a different namespace. > > Furthermore, the schema defined above and the namespace for > elements > > defined within it MUST NOT be altered by future specifications. > > Changes in the basic schema, or in the interpretation of elements > > within that schema, may result in violations of user privacy due to > > mis-interpretation of documents. > > > > If someone extends the schema defined in the draft in a new > namespace, > > the result could be a new authorization document with different > > semantics. > > Different, in the sense that it adds new permissions - yes. > different, in that it changes the meaning of existing > permissions - no. > > > > So, when applying the extended authorization > > document on a raw presence document, authorization decisions are > > probably different as when applying the same authorization document > > restricted to the "original" namespace. The question is > whether it is > > still makes sense to store the extended document under AUID > > "pres-rules" (or one should reserve a new AUID?), as > Presence Servers > > understanding only the schema defined in > > draft-ietf-simple-presence-rules-01 (and ignoring the extensions) > > could make incorrect decisions. > > I think they should all use pres-rules. I don't see what the > problem is > with doing that, or what changes if they are placed under a > different auid. > > -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 Thu Nov 4 00:31: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 AAA26493; Thu, 4 Nov 2004 00:31:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaSy-0001QI-2u; Thu, 04 Nov 2004 00:47:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPaBC-00072N-Nx; Thu, 04 Nov 2004 00:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPa5n-0006F7-Q4 for simple@megatron.ietf.org; Thu, 04 Nov 2004 00:23: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 AAA25356 for ; Thu, 4 Nov 2004 00:23:24 -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 1CPaLE-0001AH-W6 for simple@ietf.org; Thu, 04 Nov 2004 00:39:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2004 21:33:29 -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 iA45MinC015947; Wed, 3 Nov 2004 21:22:47 -0800 (PST) Received: from [10.6.60.52] (sjc-vpn5-161.cisco.com [10.21.88.161]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFN13504; Wed, 3 Nov 2004 21:22:48 -0800 (PST) Message-ID: <41896F6A.8060705@cisco.com> Date: Wed, 03 Nov 2004 18:53:14 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis Subject: Re: [Simple] Re: pres-rules: extensibility References: <20041103195314.EFZN10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> In-Reply-To: <20041103195314.EFZN10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: krisztian.kiss@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Thanos Diacakis wrote: > If any extensions make the authorization rules more restrictive, then an > application that doesn't understand the extensions, would not be able to > apply them correctly. The authorization policies are designed to be privacy safe. New permissions defined in extensions can only grant access to data - they can never restrict it. As such, if a client places a document onto a server, and the server doesn't understand some of the extensions, in the worst case, the server will give out less information than the presentity had desired. In any case, if xcap is used, the client can discover what namespaces are understood by the server ahead of time, and avoid using permissions the server won't understand. > > Using the same AUID would tell the application that the contents of the > documents conform to the semantics of "presence-rules", which would clearly > not be the case. It is the case; presence-rules were designed to support extensibility, and the model above is part of that. > > If a different AUID was used, then the application would have to understand > that AUID and what the semantical implications are, due to the utilized > extensions. I just don't see how this can work. If you assign an auid for each extension (i.e., for each new schema/namespace that defines new permissions), what would you do with a document that contains permissions from multiple namespaces? This ends up being a combinatorial explosion. -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 Thu Nov 4 00:32: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 AAA26724; Thu, 4 Nov 2004 00:32:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaUU-0001UP-63; Thu, 04 Nov 2004 00:48:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPaBD-00072p-Hn; Thu, 04 Nov 2004 00:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPa5n-0006F8-OT for simple@megatron.ietf.org; Thu, 04 Nov 2004 00:23: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 AAA25357 for ; Thu, 4 Nov 2004 00:23:24 -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 1CPaLE-0001AI-WC for simple@ietf.org; Thu, 04 Nov 2004 00:39:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2004 21:35:40 -0800 X-BrightmailFiltered: true 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 iA45MlnC015967; Wed, 3 Nov 2004 21:22:47 -0800 (PST) Received: from [10.6.60.52] (sjc-vpn5-161.cisco.com [10.21.88.161]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFN13505; Wed, 3 Nov 2004 21:22:50 -0800 (PST) Message-ID: <41897027.9060005@cisco.com> Date: Wed, 03 Nov 2004 18:56:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis Subject: Re: [Simple] Re: pres-rules/common-pol: splitting and References: <20041103194920.EFAE10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> In-Reply-To: <20041103194920.EFAE10825.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: krisztian.kiss@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Thanos Diacakis wrote: > So an implementation would need to evaluate the conditions in *every* row, > whenever a subscription is received *and* everytime a notification is about > to be sent? No. Sorry I was not being clear. Assuming you are associating a condition with a "row" in a database, the presence rules specification will call out which rows are applicable to processing the subscription, and which are needed for processing the privacy filtering before a notification is sent. The document doesn't do that now. I will correct that in the next revision. > > That doesn't seem like a very efficient way of doing things. > > I think having those into two tables, would make life easier. If you're > trying to decide whether you're authorizing a sub, you look in the one > table. Conversely, if you're trying to determine what transformations to > apply to send out a notification, you look at the other table. An implementation that works this way is possible. -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 Thu Nov 4 00:33:36 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 AAA26885; Thu, 4 Nov 2004 00:33:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaV8-0001W9-I1; Thu, 04 Nov 2004 00:49:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPaBF-00073P-25; Thu, 04 Nov 2004 00:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPa5n-0006F9-Uo for simple@megatron.ietf.org; Thu, 04 Nov 2004 00:23: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 AAA25363 for ; Thu, 4 Nov 2004 00:23:24 -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 1CPaLG-0001AI-Jm for simple@ietf.org; Thu, 04 Nov 2004 00:39:27 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2004 21:35:56 -0800 X-BrightmailFiltered: true 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 iA45N8cp023353; Wed, 3 Nov 2004 21:23:08 -0800 (PST) Received: from [10.6.60.52] (sjc-vpn5-161.cisco.com [10.21.88.161]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFN13515; Wed, 3 Nov 2004 21:23:06 -0800 (PST) Message-ID: <4189ABDE.7080505@cisco.com> Date: Wed, 03 Nov 2004 23:11:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <4185B95C.3050105@cs.columbia.edu> <41869E22.7090401@cisco.com> <4186A0E8.3010203@cs.columbia.edu> In-Reply-To: <4186A0E8.3010203@cs.columbia.edu> 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: Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> >> Perhaps I've missed it through the long chains of emails, but you can >> concisely state what is it you want that to mean? The two suggested so >> far were (1) different views of the same service from different >> sources which could not be reconciled by the compositor, and so are >> presented to the watcher for reconciliation, and (2) or-of-and kind of >> capability declarations. > > > Multiple components of the service whose capabilities cannot be > represented by a simple merger without loss of information. > > >> >> My view on (2), which I've stated in a previous response, is that you >> are better off just removing cpabilities which conflict between >> different services used as input to composition. > > > Not sure if I understand the proposal correctly, but are you suggesting > that if one publishing entity for the AOR has text capabilities and the > other doesn't, that the single service tuple not advertise text at all? Right. This is based on the premise that the characteristics and status in the tuple form a "loose contract". Its loose in that there are no guarantees, but it is meant to represent the nature of the service you are going to get if you hit that URI. In that regard, if I have two devices hiding behind an AOR, and they have different capabilities for media (for example), there is nothing I can concretely say about the nature of the service I'll get at that URI, so I say nothing. This is consistent with the view of how callee caps are applied to an AOR in RFC3840, which says the same thing - if a capability is not shared by all components of the aor, you cannot bind it to the AOR. If you want to advertise the component services, you need to use a different URI for each one (i.e., gruu). Thus, you can have it both ways. > > In that case, what would happen with two tuples with the same AOR? > > (1) If the watcher supports caller prefs (or the equivalent for other > URIs, as in my example of content-negotiation for HTTP), it can pick the > service capability combination that actually exists. I very much dislike the idea of requiring in any way the watcher to have to do something special to reach that particular service. Why not make it easy and just include the gruu instead of the aor? This way, the caller can pick which one of these it wants without having to play the callerprefs guessing game. > > (2) If the watcher does not support caller prefs (but understands > capabilities), it can do the merging, but know that it might not be able > to steer the call, so the result may or may not be optimal. Having one > tuple makes this no more or less likely. Right. > > (3) If the watcher doesn't support callerprefs nor understands > capabilities in presence, it just sees two tuples that look the same in > the parts that it cares about and merges them. No harm done. > > Since the compositor cannot know whether the watcher is in category (1), > (2) or (3), it seems inappropriate for the compositor to rule out > capable watchers, particularly since not-so-bright watchers are no worse > of with the extra information. I think this argument you are making would only support the proposal here. Since the presenitty cannot know whether the watcher has caller prefs, I think it is bad to depend on them in any way. As a result, if it wants to report two components of the same service as differing, with a choice to the watcher, it uses a gruu so that the watcher just picks which URI it wants and uses it. People seem bothered by usage of gruu here. I'm not sure I understand that. -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 Thu Nov 4 00:38: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 AAA27782; Thu, 4 Nov 2004 00:38:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaZQ-0001hW-9B; Thu, 04 Nov 2004 00:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPaBJ-00074M-8S; Thu, 04 Nov 2004 00:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPa60-0006Fc-GQ for simple@megatron.ietf.org; Thu, 04 Nov 2004 00:23:40 -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 AAA25437 for ; Thu, 4 Nov 2004 00:23:37 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaLT-0001Ar-0o for simple@ietf.org; Thu, 04 Nov 2004 00:39:39 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 03 Nov 2004 21:23:19 -0800 X-BrightmailFiltered: true 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 iA45NAVB018369; Wed, 3 Nov 2004 21:23:10 -0800 (PST) Received: from [10.6.60.52] (sjc-vpn5-161.cisco.com [10.21.88.161]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFN13519; Wed, 3 Nov 2004 21:23:09 -0800 (PST) Message-ID: <4189ADE9.2000908@cisco.com> Date: Wed, 03 Nov 2004 23:19:53 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <1098274146.18584.58.camel@hed039-183.research.nokia.com> <41774342.4020008@dynamicsoft.com> <1098709034.5794.55.camel@hed039-183.research.nokia.com> <417D7C0B.9020806@cisco.com> <1098789320.15902.192.camel@hed039-183.research.nokia.com> <417E65A3.6080802@cisco.com> <4185A94B.4080303@cs.columbia.edu> <4186833E.3070108@cisco.com> <41870784.60604@cs.columbia.edu> In-Reply-To: <41870784.60604@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> In principle, if they are published as separate tuples, then a watcher >> could reach the right one by both using the address and including >> explicit callerprefs to select the features desired among those >> advertised. But We have agreed it is unreasonable to expect watchers >> to do that. > > > There is a subtle point here that seems to keep getting lost: I agree > that we cannot *expect* a watcher to do this. I want to *allow* a > watcher with that capability to do this. You and Jonathan, if I > understand you correctly, don't want to allow me to build a system that > leverages this capability. Nothing can stop a watcher from using caller prefs on a tuple. However, the point of advertising multiple tuples in a presence document is to give a watcher choice in selecting one or the other. What I object to is telling the watcher that they do indeed have a choice, but not provide them the tools to make that choice. Instead, the only way that they can make a choice is to try and force routing by caller prefs, which is known to be problematic, and is why we eventually specified gruu. If you don't provide the tools for making the choice in the presence document (invoking one URI or another), then don't offer a choice. As such, what I am saying is that there are several options for the compositor: 1. offer each published service as a separate tuple using the gruu for each 2. combine the two so that the tuple only contains information common between the two published services, and the contact URI is the aor 3. combine the two so that the tuple contains a union of information. This violates the "loose contract" of the presence document, but there are no presence police so it remains a choice. I don't see any loss of functionality here at all. All I see is that there is a need to use gruu instead of caller prefs to select a service, something we've concluded is the right thing for other similar problems. -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 Thu Nov 4 09:18: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 JAA23432; Thu, 4 Nov 2004 09:18:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPihZ-0005Bq-P0; Thu, 04 Nov 2004 09:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiLh-0008ON-El; Thu, 04 Nov 2004 09:12:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiF3-0007Jx-IQ for simple@megatron.ietf.org; Thu, 04 Nov 2004 09:05: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 JAA21950 for ; Thu, 4 Nov 2004 09:05:32 -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 1CPiUZ-0004mO-SX for simple@ietf.org; Thu, 04 Nov 2004 09:21:37 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2004 06:15:39 -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 iA4E4tnC008769; Thu, 4 Nov 2004 06:04:56 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMU28245; Thu, 4 Nov 2004 09:04:57 -0500 (EST) Message-ID: <418A3709.5000105@cisco.com> Date: Thu, 04 Nov 2004 09:04:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <4185B95C.3050105@cs.columbia.edu> <41869E22.7090401@cisco.com> <4186A0E8.3010203@cs.columbia.edu> <4189ABDE.7080505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Trimmed. Comment at end. Paul Jonathan Rosenberg wrote: > >> In that case, what would happen with two tuples with the same AOR? >> >> (1) If the watcher supports caller prefs (or the equivalent for other >> URIs, as in my example of content-negotiation for HTTP), it can pick >> the service capability combination that actually exists. > > I very much dislike the idea of requiring in any way the watcher to have > to do something special to reach that particular service. Why not make > it easy and just include the gruu instead of the aor? This way, the > caller can pick which one of these it wants without having to play the > callerprefs guessing game. > >> (2) If the watcher does not support caller prefs (but understands >> capabilities), it can do the merging, but know that it might not be >> able to steer the call, so the result may or may not be optimal. >> Having one tuple makes this no more or less likely. > > Right. > >> (3) If the watcher doesn't support callerprefs nor understands >> capabilities in presence, it just sees two tuples that look the same >> in the parts that it cares about and merges them. No harm done. >> >> Since the compositor cannot know whether the watcher is in category >> (1), (2) or (3), it seems inappropriate for the compositor to rule out >> capable watchers, particularly since not-so-bright watchers are no >> worse of with the extra information. > > I think this argument you are making would only support the proposal > here. Since the presenitty cannot know whether the watcher has caller > prefs, I think it is bad to depend on them in any way. As a result, if > it wants to report two components of the same service as differing, with > a choice to the watcher, it uses a gruu so that the watcher just picks > which URI it wants and uses it. > > People seem bothered by usage of gruu here. I'm not sure I understand that. I think that using GRUUs is the "best" answer here. But I think the jury is out on how often that will be an option. There are a couple of reasons they might not be: - the registrar and/or the UA may not support GRUU. It certainly isn't widely supported yet. And both need to support it before it can be available in published tuples. - in theory the PS itself could assign GRUUs for the tuples, and then proxy requests to them, using the AOR and callerprefs to steer the request. But this is also a big burden, and something it may not be reasonable to expect the PS to do. As a result, I think, like it or not, there will be a lot of abuse of the system, with diverse UAs using their AOR as the tuple contact. I think we need to make the best of a bad situation. Including multiple tuples with the same contact does provide the subscriber with extra information compared with merging them and supressing the differences. And this is just one option for the compositor. The other options you have mentioned are still available. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 4 10:22: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 KAA00051; Thu, 4 Nov 2004 10:22:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjhN-0006nl-8z; Thu, 04 Nov 2004 10:38:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjA6-00059i-EB; Thu, 04 Nov 2004 10:04:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPj8b-0003J0-GH for simple@megatron.ietf.org; Thu, 04 Nov 2004 10:02: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 KAA27210 for ; Thu, 4 Nov 2004 10:02:55 -0500 (EST) Received: from il-tlv-smtpgateway.comverse.com ([192.118.48.242] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjO8-0006Hr-11 for simple@ietf.org; Thu, 04 Nov 2004 10:19:01 -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 iA4F2iD12318 for ; Thu, 4 Nov 2004 17:02:44 +0200 Received: from il-tlv-mail02.comverse.com ([10.115.242.26]) by il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Nov 2004 17:02:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Nov 2004 17:02:53 +0200 Message-ID: <522B9797154BD549B17BA4EAF1DF200C10827E@il-tlv-mail02.comverse.com> Thread-Topic: Watcher Info Thread-Index: AcTCf1vYiadL7jUvTp6K32zaMYBzrg== From: "Nevo Oded" To: X-OriginalArrivalTime: 04 Nov 2004 15:02:53.0719 (UTC) FILETIME=[5C3A8270:01C4C27F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Simple] Watcher Info X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1824382206==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. --===============1824382206== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C27F.5C10B327" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C27F.5C10B327 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi All=20 I want to know what is your recommendation about maintenance=20 Of watchers info list. Should the list be kept as a resource in the RLS or should it be = generated By the PS according to watchers subscriptions to specific presentity? 10x Oded Nevo=20 ------_=_NextPart_001_01C4C27F.5C10B327 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Watcher Info

Hi All =

I want = to know what is your recommendation about maintenance

Of = watchers info list.

Should = the list be kept as a resource in the RLS or should it be = generated

By the = PS according to watchers subscriptions to specific = presentity?

10x Oded = Nevo

------_=_NextPart_001_01C4C27F.5C10B327-- --===============1824382206== 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 --===============1824382206==-- From simple-bounces@ietf.org Thu Nov 4 14:34: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 OAA25294; Thu, 4 Nov 2004 14:34:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPncd-0004on-Hu; Thu, 04 Nov 2004 14:50:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPnCT-0002zI-4E; Thu, 04 Nov 2004 14:23:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPn8T-0002CV-BF for simple@megatron.ietf.org; Thu, 04 Nov 2004 14:19: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 OAA23759 for ; Thu, 4 Nov 2004 14:19:04 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnO3-0004U3-CA for simple@ietf.org; Thu, 04 Nov 2004 14:35:11 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4JJ1311311; Thu, 4 Nov 2004 21:19:02 +0200 (EET) X-Scanned: Thu, 4 Nov 2004 21:16:54 +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 iA4JGskT016873; Thu, 4 Nov 2004 21:16:54 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00hFVxcl; Thu, 04 Nov 2004 21:16:53 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4JGCS24424; Thu, 4 Nov 2004 21:16:12 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 21:16:11 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 21:16:11 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 21:16:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Nov 2004 21:16:11 +0200 Message-ID: Thread-Topic: Partial-PIDF and PRESCAPS-EXT Thread-Index: AcTCn78c+/eCwkWMTKGQItnf66dB9QAAbDqA To: X-OriginalArrivalTime: 04 Nov 2004 19:16:10.0953 (UTC) FILETIME=[BE7C6390:01C4C2A2] X-Spam-Score: 0.5 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: simple@ietf.org Subject: [Simple] RE: Partial-PIDF and PRESCAPS-EXT X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0033154415==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 This is a multi-part message in MIME format. --===============0033154415== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C2A2.BE8AD8A4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C2A2.BE8AD8A4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Thanks for careful reading. You are right. There is a bug in the examples. Correct namespace is = urn:ietf:params:ns:pidf:servcaps. Will be fixed. =20 - Mikko -----Original Message----- From: ext Sharon Fridman [mailto:Sharon.Fridman@followap.com] Sent: 04 November, 2004 20:55 To: Lonnfors Mikko (Nokia-NRC/Helsinki) Cc: simple@ietf.org Subject: Partial-PIDF and PRESCAPS-EXT Hi! =20 The examples in section 7 use the namespace URN = "urn:ietf:params:xml:ns:pidf:status:servcaps" and = "urn:ietf:params:xml:ns:pidf:status:devcaps" relating to = draft-ietf-simple-prescaps-ext-02. =20 Prescaps section 7.1 indicates URN = "urn:ietf:params:xml:ns:pidf:servcaps" with URI = "urn:ietf:params:xml:ns:pidf:status:servcaps" which is not consistent. = Also the XML fragment uses the status format. =20 According to my understanding this draft specifically identify the = service data as static characteristics (using the presence model terms) = and thus require this to be child of rather than (as = shown in the sample) and also using URN = "ietf:params:xml:ns:pidf:servcaps" (Section 3.2 of prescaps-02). =20 Please advise, -Fridy / Followap ------_=_NextPart_001_01C4C2A2.BE8AD8A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Thanks=20 for careful reading.
You=20 are right. There is a bug in the examples. Correct namespace is=20 urn:ietf:params:ns:pidf:servcaps. Will be fixed.
 
-=20 Mikko
-----Original Message-----
From: ext Sharon Fridman = [mailto:Sharon.Fridman@followap.com]
Sent: 04 November, 2004 = 20:55
To: Lonnfors Mikko (Nokia-NRC/Helsinki)
Cc:=20 simple@ietf.org
Subject: Partial-PIDF and=20 PRESCAPS-EXT

Hi!

 

The examples in section = 7 use the=20 namespace URN = “urn:ietf:params:xml:ns:pidf:status:servcaps” = and=20 “urn:ietf:params:xml:ns:pidf:status:devcaps” relating to=20 draft-ietf-simple-prescaps-ext-02.

 

Prescaps section 7.1 indicates  URN=20 “urn:ietf:params:xml:ns:pidf:servcaps” with URI=20 “urn:ietf:params:xml:ns:pidf:status:servcaps” which is not = consistent. Also=20 the XML fragment uses the status format.

 

According to my understanding this draft = specifically=20 identify the service data as static characteristics (using the = presence model=20 terms) and thus require this to be child of <tuple> rather than=20 <status> (as shown in the sample) and also using URN=20 “ietf:params:xml:ns:pidf:servcaps” (Section 3.2 of =20 prescaps-02).

 

Please advise,

-Fridy /=20 Followap

------_=_NextPart_001_01C4C2A2.BE8AD8A4-- --===============0033154415== 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 --===============0033154415==-- From simple-bounces@ietf.org Fri Nov 5 05:09:27 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 FAA24653; Fri, 5 Nov 2004 05:09:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ1Hq-0006tx-T1; Fri, 05 Nov 2004 05: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 1CQ0Sq-000611-Gt; Fri, 05 Nov 2004 04:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0RX-0005f8-49 for simple@megatron.ietf.org; Fri, 05 Nov 2004 04:31: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 EAA19884 for ; Fri, 5 Nov 2004 04:31:33 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0hB-0005t8-O5 for simple@ietf.org; Fri, 05 Nov 2004 04:47:50 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59V1qN022705 for ; Fri, 5 Nov 2004 10:31:04 +0100 Message-Id: <200411050931.iA59V1qN022705@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:31:00 +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: AcTDGimknHbIyWlORQyWjv5f4VLvUA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [Simple] WiMAX Summit: Call for proposals X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664131145==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 This is a multi-part message in MIME format. --===============0664131145== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0102_01C4C322.8BC11DD0" This is a multi-part message in MIME format. ------=_NextPart_000_0102_01C4C322.8BC11DD0 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, next April 5-8 2005, by distinguished experts and key players in the field. The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/wimax05/wimax2005intro.htm ------=_NextPart_000_0102_01C4C322.8BC11DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = 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, next April 5-8 2005, by distinguished = experts and key players in the field.

 

The call for proposal dead line has been = extended to November 30.

 

Details at:

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

 

------=_NextPart_000_0102_01C4C322.8BC11DD0-- --===============0664131145== 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 --===============0664131145==-- From simple-bounces@ietf.org Fri Nov 5 10:50: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 KAA23060; Fri, 5 Nov 2004 10:50:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ6bq-000614-Go; Fri, 05 Nov 2004 11:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6I6-0006C6-Dj; Fri, 05 Nov 2004 10:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ66Y-0007ng-9Z for simple@megatron.ietf.org; Fri, 05 Nov 2004 10:34: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 KAA21953 for ; Fri, 5 Nov 2004 10:34:19 -0500 (EST) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ6MH-0005f6-Tx for simple@ietf.org; Fri, 05 Nov 2004 10:50:39 -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 iA5FYI305624 for ; Fri, 5 Nov 2004 17:34:18 +0200 (EET) X-Scanned: Fri, 5 Nov 2004 17:33:43 +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 iA5FXhrU004680 for ; Fri, 5 Nov 2004 17:33:43 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00V8qOOC; Fri, 05 Nov 2004 17:33:42 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 iA5FXea14277 for ; Fri, 5 Nov 2004 17:33:40 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Nov 2004 17:33:40 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Nov 2004 17:33:40 +0200 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 Date: Fri, 5 Nov 2004 17:33:39 +0200 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8C2C@esebe056.ntc.nokia.com> Thread-Topic: IETF61 SIMPLE agenda Thread-Index: AcTALpbcsVzNMQWsQkmxZXdUfJxqgwDHbfeQ To: X-OriginalArrivalTime: 05 Nov 2004 15:33:40.0584 (UTC) FILETIME=[D3757E80:01C4C34C] X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: IETF61 SIMPLE agenda X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable A revised agenda can now be found at http://www.softarmor.com/simple/meets/ietf61/agenda.html Regards, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: 01.November.2004 18:19 > To: simple@ietf.org > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Subject: IETF61 SIMPLE agenda >=20 >=20 > Folks - Here's the current plan for our meetings in DC. > Feel free to suggest adjustments. >=20 > RjS >=20 >=20 > SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) > IETF61 >=20 > Tuesday, November 9, 2004 > 1545-1645 Afternoon Session III and 1700-1800 Afternoon Session IV >=20 > 15m Administrivia - Chairs >=20 > 1h MSRP - Ben Campbell, Cullen Jennings > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-message-=20 > sessions-09.txt > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays=20 > -02.txt >=20 > 30m Presence Rules - Jonathan Rosenberg > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules=20 > -01.txt >=20 > Wednesday, November 10, 2004 > 0900-1130 Morning Session >=20 > 1h 45m Presence Data Model / RPID - Jonathan=20 > Rosenberg, Henning =20 > Schulzrinne > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-=20 > model-01.txt > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-04.txt >=20 > 30m Partial Notify/Publish - Aki Niemi, Mikko Lonnfors > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-=20 > publish-01.txt > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-=20 > format-02.txt > =09 http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify=20 -03.txt 15m Prescaps - Mikko Lonnfors =09 http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext=20 -02.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 5 17:04: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 RAA23742; Fri, 5 Nov 2004 17:04:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQCBf-0005jb-Se; Fri, 05 Nov 2004 17:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQC7D-0000gb-0p; Fri, 05 Nov 2004 16:59:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmtx-0007hz-1X for simple@megatron.ietf.org; Thu, 04 Nov 2004 14:04: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 OAA22610 for ; Thu, 4 Nov 2004 14:04:03 -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 1CPn9W-00048L-DH for simple@ietf.org; Thu, 04 Nov 2004 14:20:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Nov 2004 20:54:43 +0200 Message-ID: <8993B20049600A40B0AEAFD6F736C9DFF9868E@MHAIFA.followap.com> X-MS-Has-Attach: yes Thread-Topic: Partial-PIDF and PRESCAPS-EXT Thread-Index: AcTCn78c+/eCwkWMTKGQItnf66dB9Q== From: "Sharon Fridman" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b X-Mailman-Approved-At: Fri, 05 Nov 2004 16:59:25 -0500 Cc: simple@ietf.org Subject: [Simple] Partial-PIDF and PRESCAPS-EXT X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0062105205==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b This is a multi-part message in MIME format. --===============0062105205== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C4C2A0.61686FBA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C2A0.61686FBA Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4C2A0.61686FBA" ------_=_NextPart_002_01C4C2A0.61686FBA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi! =20 The examples in section 7 use the namespace URN "urn:ietf:params:xml:ns:pidf:status:servcaps" and "urn:ietf:params:xml:ns:pidf:status:devcaps" relating to draft-ietf-simple-prescaps-ext-02. =20 Prescaps section 7.1 indicates URN "urn:ietf:params:xml:ns:pidf:servcaps" with URI "urn:ietf:params:xml:ns:pidf:status:servcaps" which is not consistent. Also the XML fragment uses the status format. =20 According to my understanding this draft specifically identify the service data as static characteristics (using the presence model terms) and thus require this to be child of rather than (as shown in the sample) and also using URN "ietf:params:xml:ns:pidf:servcaps" (Section 3.2 of prescaps-02). =20 Please advise, -Fridy / Followap ------_=_NextPart_002_01C4C2A0.61686FBA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi!

 

The examples in section 7 use the namespace URN = “urn:ietf:params:xml:ns:pidf:status:servcaps” and “urn:ietf:params:xml:ns:pidf:status:devcaps” relating to = draft-ietf-simple-prescaps-ext-02.

 

Prescaps section 7.1 indicates  URN = “urn:ietf:params:xml:ns:pidf:servcaps” with URI “urn:ietf:params:xml:ns:pidf:status:servcaps” which = is not consistent. Also the XML fragment uses the status = format.

 

According to my understanding this draft specifically identify = the service data as static characteristics (using the presence model terms) and thus require this to be child of <tuple> rather than <status> (as = shown in the sample) and also using URN = “ietf:params:xml:ns:pidf:servcaps” (Section 3.2 of  prescaps-02).

 

Please advise,

-Fridy / Followap

------_=_NextPart_002_01C4C2A0.61686FBA-- ------_=_NextPart_001_01C4C2A0.61686FBA Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: 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_01C4C2A0.61686FBA-- --===============0062105205== 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 --===============0062105205==-- From simple-bounces@ietf.org Sat Nov 6 20:24: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 UAA23600; Sat, 6 Nov 2004 20:24:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQbnk-0003Bh-SU; Sat, 06 Nov 2004 20:25:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQbcK-0000rr-D1; Sat, 06 Nov 2004 20:13:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQbXT-00070S-P1 for simple@megatron.ietf.org; Sat, 06 Nov 2004 20:08: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 UAA22648 for ; Sat, 6 Nov 2004 20:08:14 -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 1CQbXh-0002rB-6n for simple@ietf.org; Sat, 06 Nov 2004 20:08:30 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2004 17:20:59 -0800 X-BrightmailFiltered: true 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 iA717ecp023695; Sat, 6 Nov 2004 17:07:40 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-496.cisco.com [10.21.81.240]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU31351; Sat, 6 Nov 2004 17:07:39 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 06 Nov 2004 16:07:54 -0800 From: Cullen Jennings To: "simple@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Paul H Kyzivat Subject: [Simple] Question about extending mood in rpids-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Say we later wanted to add the ability in the mood to say that one was feeling very fluffy today, how would we do that in a backwards compatible way? Do we need some other element or something that contains a text descriptions and perhaps icon? The way we did this looks very much like a have to get it right the first time approach. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Nov 6 20: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 UAA25357; Sat, 6 Nov 2004 20:50:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQcCN-0003k0-F6; Sat, 06 Nov 2004 20:50:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQc0y-0006jK-TF; Sat, 06 Nov 2004 20:38:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQbsI-00052A-GK for simple@megatron.ietf.org; Sat, 06 Nov 2004 20:29: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 UAA24132 for ; Sat, 6 Nov 2004 20:29:44 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQbsU-0003LG-4O for simple@ietf.org; Sat, 06 Nov 2004 20:30:01 -0500 Received: from razor.cs.columbia.edu (IDENT:nh6YmTeYsa4N4BuHip7IYpET8HOwTb1Q@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA71TYRX005975; Sat, 6 Nov 2004 20:29:34 -0500 (EST) Received: from [127.0.0.1] (IDENT:eWtW/+twmLefTDeIpyMGLX6ieH62xSSU@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA71TXXH027212; Sat, 6 Nov 2004 20:29:33 -0500 Message-ID: <418D7A7D.20007@cs.columbia.edu> Date: Sat, 06 Nov 2004 20:29:33 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] Question about extending mood in rpids-04 References: In-Reply-To: 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.11.6.0 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit The current approach would require an extension of the schema. A slightly less heavy-weight approach would be a variation of the XMPP/Jabber approach, as in The same issue exists for all the enumerations and should probably be handled in a similar fashion. Cullen Jennings wrote: > Say we later wanted to add the ability in the mood to say that one was > feeling very fluffy today, how would we do that in a backwards compatible > way? Do we need some other element or something that contains a text > descriptions and perhaps icon? The way we did this looks very much like a > have to get it right the first time approach. > > > > > _______________________________________________ > 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 Nov 7 11:21: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 LAA01131; Sun, 7 Nov 2004 11:21:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpnw-0006Kl-1B; Sun, 07 Nov 2004 11:22:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQplN-0004qB-VS; Sun, 07 Nov 2004 11:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpii-0004W1-6A for simple@megatron.ietf.org; Sun, 07 Nov 2004 11:16: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 LAA00427 for ; Sun, 7 Nov 2004 11:16:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpj4-0006Ax-LR for simple@ietf.org; Sun, 07 Nov 2004 11:17:11 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2004 08:16:21 -0800 X-BrightmailFiltered: true 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 iA7GGGJZ009993; Sun, 7 Nov 2004 08:16:17 -0800 (PST) Received: from [10.67.86.234] (sjc-vpn5-955.cisco.com [10.21.91.187]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFO79460; Sun, 7 Nov 2004 08:16:13 -0800 (PST) Message-ID: <418E21C7.90704@cisco.com> Date: Sun, 07 Nov 2004 08:23:19 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Question about extending mood in rpids-04 References: <418D7A7D.20007@cs.columbia.edu> In-Reply-To: <418D7A7D.20007@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit I think it's fairly important to get this right, and deserves some broader attention. Firstly, I think that whatever mechanism we do should definitely be applied the same across rpid elements. Right now, the schema uses several different techniques. Secondly, I think you can enumerate the approaches: 1. Generic element names In this approach, the value of the element contains the information of interest. Something like this: working Extensibility is easy; the schema allows to contain a string, and you manage this through IANA. 2. Specific element names In this approach, the element name contains the information of interest: There are two variations on this: a. the schema uses substitution groups, declaring an abstract element like that things like replace b. the schema allow elements from any namespace 3. Attribute values Attributes contain the information of interest: So, which to do? I strongly believe we should use 2a. The reasons are: I: It allows XML namespaces to easily be applied to differentiate values created by one group from those created by another, without requiring central organization through IANA for everything. II: Subtitution groups allow additional schema validation, so that things that are really an activity appear within an activity element III: It allows for values that are more structured than just a token, should the need arise Thanks, Jonathan R. Henning Schulzrinne wrote: > The current approach would require an extension of the schema. A > slightly less heavy-weight approach would be a variation of the > XMPP/Jabber approach, as in > > > > > > The same issue exists for all the enumerations and should probably be > handled in a similar fashion. > > Cullen Jennings wrote: > >> Say we later wanted to add the ability in the mood to say that one was >> feeling very fluffy today, how would we do that in a backwards compatible >> way? Do we need some other element or something that contains a text >> descriptions and perhaps icon? The way we did this looks very much like a >> have to get it right the first time approach. >> >> >> >> >> _______________________________________________ >> 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 Sun Nov 7 14:16: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 OAA14633; Sun, 7 Nov 2004 14:16:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsWn-0001R3-Ku; Sun, 07 Nov 2004 14:16:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsV6-0003i0-5Q; Sun, 07 Nov 2004 14:14:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQsSM-0002qw-9n for simple@megatron.ietf.org; Sun, 07 Nov 2004 14:12: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 OAA14201 for ; Sun, 7 Nov 2004 14:12:04 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQsSh-0001KW-Gq for simple@ietf.org; Sun, 07 Nov 2004 14:12:30 -0500 Received: from razor.cs.columbia.edu (IDENT:IW6nxzcF/SP8EJVtPspY5O0kt7fTvBeX@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA7JBxRX019566; Sun, 7 Nov 2004 14:11:59 -0500 (EST) Received: from [127.0.0.1] (IDENT:F9d9QNiEXTiLzmNJIVtZORFFXmCZu0Sc@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA7JBwXH022377; Sun, 7 Nov 2004 14:11:58 -0500 Message-ID: <418E7381.1020702@cs.columbia.edu> Date: Sun, 07 Nov 2004 14:12:01 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Question about extending mood in rpids-04 References: <418D7A7D.20007@cs.columbia.edu> <418E21C7.90704@cisco.com> In-Reply-To: <418E21C7.90704@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.11.6.0 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: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit I think we're in general agreement. The only sub-case that is not addressed is where the value is to be added by the user, not a schema. My attribute proposal discussion was only to address that particular case. It is a separate question whether we only allow IANA-sanctioned moods or whether users are allowed to create their own mood (using legal substances, naturally). Jonathan Rosenberg wrote: > I think it's fairly important to get this right, and deserves some > broader attention. > > Firstly, I think that whatever mechanism we do should definitely be > applied the same across rpid elements. Right now, the schema uses > several different techniques. > > Secondly, I think you can enumerate the approaches: > > 1. Generic element names > > In this approach, the value of the element contains the information of > interest. Something like this: > > working > > Extensibility is easy; the schema allows to contain a string, > and you manage this through IANA. > > 2. Specific element names > > In this approach, the element name contains the information of interest: > > > > There are two variations on this: > > a. the schema uses substitution groups, declaring an abstract element > like that things like replace > > b. the schema allow elements from any namespace > > 3. Attribute values > > Attributes contain the information of interest: > > > > > > > So, which to do? > > I strongly believe we should use 2a. The reasons are: > > I: It allows XML namespaces to easily be applied to differentiate values > created by one group from those created by another, without requiring > central organization through IANA for everything. > > II: Subtitution groups allow additional schema validation, so that > things that are really an activity appear within an activity element > > III: It allows for values that are more structured than just a token, > should the need arise > > > > Thanks, > Jonathan R. > > Henning Schulzrinne wrote: > >> The current approach would require an extension of the schema. A >> slightly less heavy-weight approach would be a variation of the >> XMPP/Jabber approach, as in >> >> >> >> >> >> The same issue exists for all the enumerations and should probably be >> handled in a similar fashion. >> >> Cullen Jennings wrote: >> >>> Say we later wanted to add the ability in the mood to say that one was >>> feeling very fluffy today, how would we do that in a backwards >>> compatible >>> way? Do we need some other element or something that contains a text >>> descriptions and perhaps icon? The way we did this looks very much >>> like a >>> have to get it right the first time approach. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Nov 7 17:16: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 RAA04302; Sun, 7 Nov 2004 17:16:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvLO-0006GM-CO; Sun, 07 Nov 2004 17:17:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvB7-0000vy-SN; Sun, 07 Nov 2004 17:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQv3X-0007oX-VB for simple@megatron.ietf.org; Sun, 07 Nov 2004 16:58:40 -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 QAA02187 for ; Sun, 7 Nov 2004 16:58: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 1CQv3x-0005iV-H7 for simple@ietf.org; Sun, 07 Nov 2004 16:59:05 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2004 14:09:26 -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 iA7LvinC026481; Sun, 7 Nov 2004 13:57:44 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn1-1292.cisco.com [10.21.101.12]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFO85462; Sun, 7 Nov 2004 13:58:05 -0800 (PST) Message-ID: <418E9A6C.102@cisco.com> Date: Sun, 07 Nov 2004 16:58:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Question about extending mood in rpids-04 References: <418D7A7D.20007@cs.columbia.edu> <418E21C7.90704@cisco.com> <418E7381.1020702@cs.columbia.edu> In-Reply-To: <418E7381.1020702@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Paul H Kyzivat , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I think we're in general agreement. The only sub-case that is not > addressed is where the value is to be added by the user, not a schema. > My attribute proposal discussion was only to address that particular case. These things will always be in the category of "notes" since they can only be understood by humans. I think you address that by just defining an element called note which allows that: big grin Since each mood element (i.e., each member of the substitution group) can have as complex a structure as needed, in this case, we are saying that one value, has a structure which includes a textual string for purposes of rendering to the human user. > > It is a separate question whether we only allow IANA-sanctioned moods or > whether users are allowed to create their own mood (using legal > substances, naturally). Mostly separate; using an element approach allows you to define an extensibility model where some values can be registered by IANA, and others just created and used, without fear of collision. If we do want IANA registries, we need to be sure we understand what it takes to create the registry (standards action, open registration, etc.). -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 Nov 7 17:22: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 RAA04899; Sun, 7 Nov 2004 17:22:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvRO-0006Qc-Q2; Sun, 07 Nov 2004 17:23:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvPD-0003j2-0P; Sun, 07 Nov 2004 17:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQvNx-0003Md-0K for simple@megatron.ietf.org; Sun, 07 Nov 2004 17: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 RAA04615 for ; Sun, 7 Nov 2004 17:19:42 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvOL-0006M9-TI for simple@ietf.org; Sun, 07 Nov 2004 17:20:11 -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 iA7MBTwB021526 for ; Sun, 7 Nov 2004 17:11:29 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iA7MBRwB021495 for ; Sun, 7 Nov 2004 17:11:27 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 8 Nov 2004 00:19:37 +0200 Message-ID: Thread-Topic: Mail Delivery (failure dromasca@avaya.com) Thread-Index: AcTFF94ddDHHwsW1RFWYqUj1q6LwfQAAAACn From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Simple] Out of Office AutoReply: Mail Delivery (failure dromasca@avaya.com) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0241665166==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a multi-part message in MIME format. --===============0241665166== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C517.DE1FF4B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C517.DE1FF4B0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I will be traveling for business purposes between November 7 and 19. My = e-mail connectivity may be scarce during this period, and there may be = delays in my e-mail answers. I will however check voice mail daily, and = can be reached for urgent matters at the mobile phone number = +1-917-622-7831. Regards, Dan ------_=_NextPart_001_01C4C517.DE1FF4B0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: <Possible SPAM> Mail Delivery = (failure dromasca@avaya.com)

I will be traveling for business purposes between = November 7 and 19.  My e-mail connectivity may be scarce during = this period, and there may be delays in my e-mail answers. I will = however check voice mail daily, and can be reached for urgent matters at = the mobile phone number +1-917-622-7831.

Regards,

Dan

------_=_NextPart_001_01C4C517.DE1FF4B0-- --===============0241665166== 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 --===============0241665166==-- From simple-bounces@ietf.org Mon Nov 8 12:37:35 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 MAA05105; Mon, 8 Nov 2004 12:37:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRDT4-000846-SI; Mon, 08 Nov 2004 12:38:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRDFw-0006CE-4A; Mon, 08 Nov 2004 12:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCtj-0007aY-5t for simple@megatron.ietf.org; Mon, 08 Nov 2004 12:01: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 MAA01505 for ; Mon, 8 Nov 2004 12:01:40 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCuH-00079E-Vk for simple@ietf.org; Mon, 08 Nov 2004 12:02:19 -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 iA8H0UW29108; Mon, 8 Nov 2004 19:00:31 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 18:59:51 +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 iA8GxpdC009830; Mon, 8 Nov 2004 18:59:51 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00n45tt7; Mon, 08 Nov 2004 18:56:58 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 iA8GuvS13518; Mon, 8 Nov 2004 18:56:57 +0200 (EET) Received: from [130.129.134.192] ([10.241.59.18]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 18:56:56 +0200 Message-ID: <418FA555.6020603@nokia.com> Date: Mon, 08 Nov 2004 11:56:53 -0500 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Question about extending mood in rpids-04 References: <418D7A7D.20007@cs.columbia.edu> <418E21C7.90704@cisco.com> In-Reply-To: <418E21C7.90704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2004 16:56:56.0254 (UTC) FILETIME=[F4597DE0:01C4C5B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Paul H Kyzivat , "simple@ietf.org" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Hi, Comment at the bottom. ext Jonathan Rosenberg wrote: > I think it's fairly important to get this right, and deserves some > broader attention. > > Firstly, I think that whatever mechanism we do should definitely be > applied the same across rpid elements. Right now, the schema uses > several different techniques. > > Secondly, I think you can enumerate the approaches: > > 1. Generic element names > > In this approach, the value of the element contains the information of > interest. Something like this: > > working > > Extensibility is easy; the schema allows to contain a string, > and you manage this through IANA. > > 2. Specific element names > > In this approach, the element name contains the information of interest: > > > > There are two variations on this: > > a. the schema uses substitution groups, declaring an abstract element > like that things like replace > > b. the schema allow elements from any namespace > > 3. Attribute values > > Attributes contain the information of interest: > > > > So, which to do? > > I strongly believe we should use 2a. The reasons are: > > I: It allows XML namespaces to easily be applied to differentiate values > created by one group from those created by another, without requiring > central organization through IANA for everything. > > II: Subtitution groups allow additional schema validation, so that > things that are really an activity appear within an activity element > > III: It allows for values that are more structured than just a token, > should the need arise I'm wondering about the future proofness when using the substitution groups. If the recipient is doing document validation, but doesn't possess the extension schema, will it be able to validate the document. That seems like a bad thing, especially considering a composer might need to do document validation. It should be able to transparently treat data it doesn't understand, so that extensions can be made in endpoints only without requiring a network entity to be upgraded. Therefore, 2b would seem like a better alternative here... Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 8 14:42: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 OAA19336; Mon, 8 Nov 2004 14:42:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFPb-0003Bp-Lo; Mon, 08 Nov 2004 14:42:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF30-0007pe-87; Mon, 08 Nov 2004 14:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREyJ-0005I3-RB for simple@megatron.ietf.org; Mon, 08 Nov 2004 14:14: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 OAA16127 for ; Mon, 8 Nov 2004 14:14:34 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREyu-0002IR-Oc for simple@ietf.org; Mon, 08 Nov 2004 14:15:13 -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 iA8JEJF14103; Mon, 8 Nov 2004 21:14:19 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 21:13:46 +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 iA8JDkdh008103; Mon, 8 Nov 2004 21:13:46 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QP1hFK; Mon, 08 Nov 2004 21:13:44 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 iA8JDba09030; Mon, 8 Nov 2004 21:13:37 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 21:13:37 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 21:13:36 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 21:13:36 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Question about extending mood in rpids-04 Date: Mon, 8 Nov 2004 21:13:36 +0200 Message-ID: Thread-Topic: [Simple] Question about extending mood in rpids-04 Thread-Index: AcTFuv67oOxrEPjjR3SSEQujbYTjRwAC1Rcw To: , X-OriginalArrivalTime: 08 Nov 2004 19:13:36.0455 (UTC) FILETIME=[0C0CDD70:01C4C5C7] X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, pkyzivat@cisco.com, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Hi, =20 > > 2. Specific element names > >=20 > > In this approach, the element name contains the information=20 > of interest: > >=20 > > > >=20 > > There are two variations on this: > >=20 > > a. the schema uses substitution groups, declaring an=20 > abstract element=20 > > like that things like replace > >=20 > > b. the schema allow elements from any namespace > I'm wondering about the future proofness when using the substitution=20 > groups. If the recipient is doing document validation, but doesn't=20 > possess the extension schema, will it be able to validate the=20 > document. As far as I understand, yes it can. > That seems like a bad thing, especially considering a composer might=20 > need to do document validation. It should be able to=20 > transparently treat=20 > data it doesn't understand, so that extensions can be made in=20 > endpoints=20 > only without requiring a network entity to be upgraded. >=20 > Therefore, 2b would seem like a better alternative here... My understanding about this is that only difference between A and B is = that in A you specify your new elements to inherit from the abstract = element that is defined in 'base' document. In B you would be able to = introduce any type of new element, regardless what has been defined = before. So both models have same properties what comes to schema validation. > Cheers, > Aki >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 8 15:24: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 PAA25901; Mon, 8 Nov 2004 15:24:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRG4M-0004Uh-3d; Mon, 08 Nov 2004 15:24:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFoN-0000TE-Cz; Mon, 08 Nov 2004 15:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFXf-0006cd-BR for simple@megatron.ietf.org; Mon, 08 Nov 2004 14:51:07 -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 OAA20798 for ; Mon, 8 Nov 2004 14:51:05 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFYE-0003Ww-QO for simple@ietf.org; Mon, 08 Nov 2004 14:51:45 -0500 Received: from razor.cs.columbia.edu (IDENT:mzH5WpGtOXPZCuL7BId+Oy94od85NWMz@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA8JoxRX013535; Mon, 8 Nov 2004 14:50:59 -0500 (EST) Received: from [127.0.0.1] (IDENT:Ti77uzDX0y1zS+9EFIyvbBeorMGpmlSd@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA8JowXH029216; Mon, 8 Nov 2004 14:50:59 -0500 Message-ID: <418FCE27.8010602@cs.columbia.edu> Date: Mon, 08 Nov 2004 14:51:03 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] presence data model: URI as an index References: <4175CCAE.5040508@dynamicsoft.com> <4185B95C.3050105@cs.columbia.edu> <41869E22.7090401@cisco.com> <4186A0E8.3010203@cs.columbia.edu> <4189ABDE.7080505@cisco.com> <418A3709.5000105@cisco.com> In-Reply-To: <418A3709.5000105@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.11.8.0 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit To add to this: presumably this discussion is not restricted to SIP URIs. As I pointed out earlier, HTTP URIs have similar overloading properties and no GRUU-equivalent option. It seems unwise to state a general rule for all URI schemas for all future applications, particularly since the gains of doing this are rather modest, in my opinion. > I think that using GRUUs is the "best" answer here. But I think the jury > is out on how often that will be an option. There are a couple of > reasons they might not be: > - the registrar and/or the UA may not support GRUU. > It certainly isn't widely supported yet. And both > need to support it before it can be available in > published tuples. > > - in theory the PS itself could assign GRUUs for the > tuples, and then proxy requests to them, using > the AOR and callerprefs to steer the request. But > this is also a big burden, and something it may not > be reasonable to expect the PS to do. > > As a result, I think, like it or not, there will be a lot of abuse of > the system, with diverse UAs using their AOR as the tuple contact. I > think we need to make the best of a bad situation. > > Including multiple tuples with the same contact does provide the > subscriber with extra information compared with merging them and > supressing the differences. And this is just one option for the > compositor. The other options you have mentioned are still available. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 8 15:29: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 PAA26331; Mon, 8 Nov 2004 15:29:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRG9F-0004cn-6F; Mon, 08 Nov 2004 15:29:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFp5-0001Ee-S4; Mon, 08 Nov 2004 15:09:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFdn-0007TJ-3k for simple@megatron.ietf.org; Mon, 08 Nov 2004 14:57: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 OAA21742 for ; Mon, 8 Nov 2004 14:57:25 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFeO-0003hQ-47 for simple@ietf.org; Mon, 08 Nov 2004 14:58:04 -0500 Received: from razor.cs.columbia.edu (IDENT:A3d9Tp7PHM4zlHO3NF7c/iBKdbG8WKDk@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA8JvMRX015090; Mon, 8 Nov 2004 14:57:23 -0500 (EST) Received: from [127.0.0.1] (IDENT:eblvCVjE517YpUYs1k+3GyQUZ3ITY3Q2@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA8JvMXH029349; Mon, 8 Nov 2004 14:57:22 -0500 Message-ID: <418FCFA6.2020606@cs.columbia.edu> Date: Mon, 08 Nov 2004 14:57:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Authorization Rules Discussion A: Sphere Interpretation References: <5816828233DEFA41807A6CFDFDF2343C3A8BD0@esebe056.ntc.nokia.com> <41888A67.6040807@cisco.com> <4188E20F.9080503@cs.columbia.edu> <4188E921.2060906@cisco.com> In-Reply-To: <4188E921.2060906@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.11.8.0 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit > Right. Thats why the composition algorithm needs to pick one. > That's the disagreement in a nutshell. The composition algorithm does not HAVE TO pick one and may not be able to. It may want to or be forced to expose this contradiction to the watcher. >> if I'm in sphere = work >> send elements of class 'foo' to my work buddies >> if I'm in sphere = play >> send elements of class 'bar', 'rab' and 'oof' to my play buddies > > > That wouldn't be a composition rule, it would be a privacy filtering rule. The two are closely related. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 8 21:22: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 VAA03869; Mon, 8 Nov 2004 21:22:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRLfR-0005ZU-3y; Mon, 08 Nov 2004 21:23:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRLdf-0007Zh-6I; Mon, 08 Nov 2004 21:21:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRLYV-00060I-LJ for simple@megatron.ietf.org; Mon, 08 Nov 2004 21:16:23 -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 VAA03278 for ; Mon, 8 Nov 2004 21:16:21 -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 1CRLZ8-0005Px-Dq for simple@ietf.org; Mon, 08 Nov 2004 21:17:04 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2004 18:27:21 -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 iA92FfnC027911; Mon, 8 Nov 2004 18:15:42 -0800 (PST) Received: from cisco.com (rtp-vpn1-529.cisco.com [10.82.226.17]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMW88945; Mon, 8 Nov 2004 21:15:45 -0500 (EST) Message-ID: <41902850.4030002@cisco.com> Date: Mon, 08 Nov 2004 21:15:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] Question about extending mood in rpids-04 References: 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: fluffy@cisco.com, hgs@cs.columbia.edu, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > >>I'm wondering about the future proofness when using the substitution >>groups. If the recipient is doing document validation, but doesn't >>possess the extension schema, will it be able to validate the >>document. > > > As far as I understand, yes it can. Can you explain? If I receive a document that has an element I don't understand, how can I tell it is an instance of a particular substitution group if that is what is required for the document to be valid? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 02:33: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 CAA24215; Tue, 9 Nov 2004 02:33:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRQWX-0003P5-0x; Tue, 09 Nov 2004 02:34:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRQU8-0003eY-GE; Tue, 09 Nov 2004 02:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRQTN-0003Ux-Rn for simple@megatron.ietf.org; Tue, 09 Nov 2004 02:31: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 CAA24060 for ; Tue, 9 Nov 2004 02:31:24 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRQU5-0003ME-9n for simple@ietf.org; Tue, 09 Nov 2004 02:32:09 -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 iA975rE04371; Tue, 9 Nov 2004 09:05:54 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 09:05:35 +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 iA975Zjk012299; Tue, 9 Nov 2004 09:05:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00g3sFiC; Tue, 09 Nov 2004 09:04:32 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 iA974Pa06404; Tue, 9 Nov 2004 09:04:25 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 09:04:23 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 09:00:30 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Question about extending mood in rpids-04 Date: Tue, 9 Nov 2004 09:00:31 +0200 Message-ID: Thread-Topic: [Simple] Question about extending mood in rpids-04 Thread-Index: AcTGAkXyLUqaM/kcSBGSisRMOykiHAAISxrw To: X-OriginalArrivalTime: 09 Nov 2004 07:00:30.0864 (UTC) FILETIME=[CD021100:01C4C629] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, hgs@cs.columbia.edu, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable > mikko.lonnfors@nokia.com wrote: > > =20 > >>I'm wondering about the future proofness when using the=20 > substitution=20 > >>groups. If the recipient is doing document validation, but doesn't=20 > >>possess the extension schema, will it be able to validate the=20 > >>document. > >=20 > >=20 > > As far as I understand, yes it can. >=20 > Can you explain? If I receive a document that has an element I don't=20 > understand, how can I tell it is an instance of a particular=20 > substitution group if that is what is required for the=20 > document to be valid? Lets take an example. We can have two schema definitions: 1) using substitutiongroups targetnamespace=3D"car" xmlns:tns=3D"car" And if we would define an extension it would look something like targetnamespace=3D"ext" xmlns:tns=3D"ext" xmlns:car=3D"car" Resulting XML document would be something like: 2) using xml ##other extensibility mechanism =09 And if we would define an extension it would look something like targetnamespace=3D"ext" xmlns:tns=3D"ext" xmlns:car=3D"car" Resulting XML document would be something like: Now what if the receiver of these documents doesn't understand the ext = namespace? In both cases it ignores the "ext" namespace and validates = rest of it against the "car". I am not sure if there are any cases where = validator would need to know that elements from a namespace it doesn't = understand belong to a particular substitutionGroup. Can you point out = any? Only case I might come up is: =20 and=20 In this case if I don't understand "ext" I cannot say if = really is a member of carmodel substitutionGroup but does it matter? I = can still say that there is one element (as required) but I don't = understand it. - Mikko=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 04:24:22 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 EAA04346; Tue, 9 Nov 2004 04:24:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRSFQ-0006E6-Vi; Tue, 09 Nov 2004 04: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 1CRSDi-00050r-4o; Tue, 09 Nov 2004 04:23:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRS7M-0003uf-4n for simple@megatron.ietf.org; Tue, 09 Nov 2004 04:16: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 EAA03754 for ; Tue, 9 Nov 2004 04:16:46 -0500 (EST) From: eva-maria.leppanen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRS83-00063D-K1 for simple@ietf.org; Tue, 09 Nov 2004 04:17:33 -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 iA99Ggv29984; Tue, 9 Nov 2004 11:16:42 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 11:15:46 +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 iA99Fkim007490; Tue, 9 Nov 2004 11:15:46 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00o3kIFL; Tue, 09 Nov 2004 11:14:36 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA99EZa02974; Tue, 9 Nov 2004 11:14:35 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 11:14:34 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 11:14:33 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] comments on I-D ACTION:draft-ietf-simple-presence-rules-01.txt Date: Tue, 9 Nov 2004 11:14:33 +0200 Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-01.txt Thread-Index: AcS9WihP21zhQ8edS42sJVv0tWuMKAI25Neg To: , X-OriginalArrivalTime: 09 Nov 2004 09:14:33.0593 (UTC) FILETIME=[86D91E90:01C4C63C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Hi, I have the following comments and questions for clarification regarding = the presence-rules draft. In the transformations chapter (3.3), it'd be good to clearly say which = information are automatically provided when authorizing person, device or service elements. I can quess that e.g. the PIDF = status and contact elements should be automatically provided, but are = all PIDF elements or elements defined for person and device by the data = model automatically provided? Is there some reason for not defining own element(s) for = Prescaps even when the Prescaps elements have a role in identifying = services (based on the data model)? I think that support for Prescaps = could be added already to the basic set of transformations. It is said at the end of chapter 3.1 that "If the element is = not present in the presence document, the value is set to undefined". = How should I intepret this "undefined": is the result "no match" if a = rule has a condition work and sphere's value is = "undefined"? Additionally, is the value of the sphere assumed to be = "undefined" if the 'until' attribute has been defined for it and the = sphere's value is not valid any more based on the 'until'? In the XML example, the qualified name of the attribute "foo" in the = element should be used. It's a bit unclear to me if the authorization supports having "publicly = authorized" rules. So if a rule maker omits the identity element does it = mean that any watcher identity matches (as could be assumed based on the = common-policy). BR, Eva _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 07:56: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 HAA21098; Tue, 9 Nov 2004 07:56:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVYQ-0002Dn-Jp; Tue, 09 Nov 2004 07:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVWP-0006EM-Sd; Tue, 09 Nov 2004 07:54:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVT5-0005wX-VO for simple@megatron.ietf.org; Tue, 09 Nov 2004 07:51: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 HAA20786 for ; Tue, 9 Nov 2004 07:51:26 -0500 (EST) From: eva-maria.leppanen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVTq-00028C-0q for simple@ietf.org; Tue, 09 Nov 2004 07:52:14 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9CpNv03154; Tue, 9 Nov 2004 14:51:23 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 14:52:10 +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 iA9CqAqZ003168; Tue, 9 Nov 2004 14:52:10 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00TVYuLt; Tue, 09 Nov 2004 14:52:06 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9Coka16966; Tue, 9 Nov 2004 14:50:46 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 14:50:46 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 14:50:45 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 14:50:44 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] comments on I-D ACTION:draft-ietf-simple-presence-data-model-01.txt Date: Tue, 9 Nov 2004 14:50:44 +0200 Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-presence-data-model-01.txt Thread-Index: AcS9JURV4snjKTaMQG+bxfIQ44HwDAJMenYQ To: X-OriginalArrivalTime: 09 Nov 2004 12:50:44.0960 (UTC) FILETIME=[BA62A600:01C4C65A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Hi, Just minor comments to the data model: In the examples (section 9), there are PIDF extension elements as the = and inside the element placed before the element. Isn't it so that = according to PIDF the extensions of the =20 should be placed between the and elements. I think = it's good to correct the examples. Another thing is that the "note" and "timestamp" elements of PIDF cannot = be used inside the and elements. I noticed that this has been discussed also earlier and the conclution = (?) was that a "note" element outside the tuples belongs to the = (and there is no "note" element defined for device information), but = isn't there a possibility that having presence attributes outside the = "basic" elements complicates composing, authorization settings etc.=20 BR, Eva _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 08:21: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 IAA23733; Tue, 9 Nov 2004 08:21:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVws-00039H-9x; Tue, 09 Nov 2004 08: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 1CRVk0-0008LI-Dq; Tue, 09 Nov 2004 08:08:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRVft-0007bg-BO for simple@megatron.ietf.org; Tue, 09 Nov 2004 08:04: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 IAA21885 for ; Tue, 9 Nov 2004 08:04:39 -0500 (EST) Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRVgd-0002Yp-7Z for simple@ietf.org; Tue, 09 Nov 2004 08:05:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Nov 2004 15:04:26 +0200 Message-ID: Thread-Topic: PUBLISH identifiers Thread-Index: AcTGXKQVZy7Y4sPwRcGEBbFzEA42qQ== From: "Adi Even-Tzur" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Subject: [Simple] PUBLISH identifiers X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0514820852==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d This is a multi-part message in MIME format. --===============0514820852== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C65C.A41D9104" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C65C.A41D9104 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 According to draft-ietf-sip-publish-04.txt, section 4.1, the PUBLISH identifiers are Request-URI, event type, and (optionally) an entity-tag. =20 RFC 3265, section 7.2.1 refers to the identifiers of SUBSCRIBE request and includes also the "id" parameter: " An "Event" header containing an "id" parameter never matches an "Event" header without an "id" parameter." =20 My question is regarding PUBLISH identifiers -=20 Is the "id" parameter of the event header should be a differentiator also for PUBLISH, the same as it define in rfc3265 for SUBSCRIBE-NOTIFY? =20 =20 Regards, Adi Even-Tzur. =20 ------_=_NextPart_001_01C4C65C.A41D9104 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

According to draft-ietf-sip-publish-04.txt, section = 4.1, the PUBLISH identifiers are Request-URI, event type, and (optionally) an

entity-tag.

 

RFC 3265, section 7.2.1 refers to the identifiers of SUBSCRIBE request and includes also the "id" parameter: " An = "Event" header containing an "id"

parameter never matches an "Event" header without an "id" = parameter."

 

My question is regarding PUBLISH identifiers – =

Is the "id" parameter of the event header = should be a differentiator also for PUBLISH, the same as it define in rfc3265 = for SUBSCRIBE-NOTIFY?

 

 

Regards,

Adi Even-Tzur.

 

=00 ------_=_NextPart_001_01C4C65C.A41D9104-- --===============0514820852== 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 --===============0514820852==-- From simple-bounces@ietf.org Tue Nov 9 09:05: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 JAA28761; Tue, 9 Nov 2004 09:05:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWd4-0004K7-1Z; Tue, 09 Nov 2004 09:05:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWP6-0007dV-KY; Tue, 09 Nov 2004 08:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWLi-0006zY-0c for simple@megatron.ietf.org; Tue, 09 Nov 2004 08:47: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 IAA26406 for ; Tue, 9 Nov 2004 08:47:52 -0500 (EST) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWMS-0003pf-N7 for simple@ietf.org; Tue, 09 Nov 2004 08:48:41 -0500 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 10 Nov 2004 01:08:39 +1100 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA9Dl28N024184; Wed, 10 Nov 2004 00:47:03 +1100 (EST) Received: from cisco.com (rtp-vpn3-37.cisco.com [10.82.216.37]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX09103; Tue, 9 Nov 2004 08:47:12 -0500 (EST) Message-ID: <4190CA60.8080106@cisco.com> Date: Tue, 09 Nov 2004 08:47:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] Question about extending mood in rpids-04 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, hgs@cs.columbia.edu, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Response near the end. Paul mikko.lonnfors@nokia.com wrote: >>mikko.lonnfors@nokia.com wrote: >> >>> >>> >>>>I'm wondering about the future proofness when using the >>> >>substitution >> >>>>groups. If the recipient is doing document validation, but doesn't >>>>possess the extension schema, will it be able to validate the >>>>document. >>> >>> >>>As far as I understand, yes it can. >> >>Can you explain? If I receive a document that has an element I don't >>understand, how can I tell it is an instance of a particular >>substitution group if that is what is required for the >>document to be valid? > > > Lets take an example. We can have two schema definitions: > > 1) using substitutiongroups > > targetnamespace="car" > xmlns:tns="car" > > > > ref="tns:carmodel" > maxOccurs="unbounded"/> > > > > > > > > > And if we would define an extension it would look something like > > targetnamespace="ext" > xmlns:tns="ext" > xmlns:car="car" > > > > Resulting XML document would be something like: > > > xmlns:ext="ext"> > > > > > 2) using xml ##other extensibility mechanism > > > > > > processContents="lax" minOccurs="0" > maxOccurs="unbounded"/> > > > > And if we would define an extension it would look something like > > targetnamespace="ext" > xmlns:tns="ext" > xmlns:car="car" > > > > Resulting XML document would be something like: > > > xmlns:ext="ext"> > > > > > Now what if the receiver of these documents doesn't understand > the ext namespace? In both cases it ignores the "ext" namespace > and validates rest of it against the "car". I am not sure if > there are any cases where validator would need to know that > elements from a namespace it doesn't understand belong to a > particular substitutionGroup. Can you point out any? I'm not sure the difference matters much, but when the extension is introduced via the ##other mechanism, if the application understands then it knows that satisfies the schema even without knowledge of ext. But with the substitution group it has no way to know whether the usage of satisfies the schema. Paul > Only case I might come up is: > > > > ref="tns:carmodel" > maxOccurs="1" > minOccurs="1"/> > > > > > and > > > xmlns:ext="ext"> > > > > In this case if I don't understand "ext" I cannot say if > really is a member of carmodel substitutionGroup > but does it matter? I can still say that there is one element > (as required) but I don't understand it. > > - Mikko > > >> Paul >> >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 09:46: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 JAA03331; Tue, 9 Nov 2004 09:46:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXGz-0005Nx-Bx; Tue, 09 Nov 2004 09:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRX77-0000aM-VA; Tue, 09 Nov 2004 09:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWzd-000765-Cn for simple@megatron.ietf.org; Tue, 09 Nov 2004 09:29:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01590 for ; Tue, 9 Nov 2004 09:29:07 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRX0O-0004z4-1x for simple@ietf.org; Tue, 09 Nov 2004 09:29:56 -0500 Received: from [130.129.133.194] ([130.129.133.194]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA9ET5RI031175 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 9 Nov 2004 08:29:06 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Simple] PUBLISH identifiers Date: Tue, 9 Nov 2004 08:29:11 -0600 To: "Adi Even-Tzur" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable That's a good question. The parameter exists in 3265 to differentiate multiple subscriptions to the same Event in the same dialog. Publish does involve a dialog, so the presence or absence of an id parameter (with any syntactically valid value) will have no effect on the processing of that Publish. 3903 doesn't talk about that parameter at all. We should queue up a clarification that the only part of the Event header field that=20 affects Publish processing is the event-type field. RjS On Nov 9, 2004, at 7:04 AM, Adi Even-Tzur wrote: > Hi, > > =A0 > > According to draft-ietf-sip-publish-04.txt, section 4.1, the PUBLISH=20= > identifiers are Request-URI, event type, and (optionally) an > > entity-tag. > > =A0 > > RFC 3265, section 7.2.1 refers to the identifiers of SUBSCRIBE request=20= > and includes also the "id" parameter: " An "Event" header containing=20= > an "id" > > parameter never matches an "Event" header without an "id" parameter." > > =A0 > > My question is regarding PUBLISH identifiers =96 > > Is the "id" parameter of the event header should be a differentiator=20= > also for PUBLISH, the same as it define in rfc3265 for=20 > SUBSCRIBE-NOTIFY? > > =A0 > > =A0 > > Regards, > > Adi Even-Tzur. > > =A0 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 10:03: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 KAA05410; Tue, 9 Nov 2004 10:03:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXY6-0005r5-Jl; Tue, 09 Nov 2004 10:04:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXT9-0005Kr-Dw; Tue, 09 Nov 2004 09:59:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXLI-0003Rg-03 for simple@megatron.ietf.org; Tue, 09 Nov 2004 09:51:32 -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 JAA03866 for ; Tue, 9 Nov 2004 09:51:29 -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 1CRXM1-0005Vl-FS for simple@ietf.org; Tue, 09 Nov 2004 09:52:18 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2004 07:04:42 -0800 X-BrightmailFiltered: true 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 iA9Eoqcp015690; Tue, 9 Nov 2004 06:50:55 -0800 (PST) Received: from cisco.com (rtp-vpn3-37.cisco.com [10.82.216.37]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX13826; Tue, 9 Nov 2004 09:50:52 -0500 (EST) Message-ID: <4190D94C.8010801@cisco.com> Date: Tue, 09 Nov 2004 09:50:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] PUBLISH identifiers References: Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA03866 Cc: simple@ietf.org, Adi Even-Tzur X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Robert Sparks wrote: > That's a good question. >=20 > The parameter exists in 3265 to differentiate multiple subscriptions > to the same Event in the same dialog. Publish does involve a dialog, ^ not > so the presence or absence of an id parameter (with any syntactically > valid value) will have no effect on the processing of that Publish. The statement is valid with the correction, so I guess this was just a ty= po. Paul > 3903 doesn't talk about that parameter at all. We should queue up > a clarification that the only part of the Event header field that affec= ts > Publish processing is the event-type field. >=20 > RjS >=20 > On Nov 9, 2004, at 7:04 AM, Adi Even-Tzur wrote: >=20 >> Hi, >> >> =20 >> >> According to draft-ietf-sip-publish-04.txt, section 4.1, the PUBLISH=20 >> identifiers are Request-URI, event type, and (optionally) an >> >> entity-tag. >> >> =20 >> >> RFC 3265, section 7.2.1 refers to the identifiers of SUBSCRIBE request= =20 >> and includes also the "id" parameter: " An "Event" header containing=20 >> an "id" >> >> parameter never matches an "Event" header without an "id" parameter." >> >> =20 >> >> My question is regarding PUBLISH identifiers =96 >> >> Is the "id" parameter of the event header should be a differentiator=20 >> also for PUBLISH, the same as it define in rfc3265 for SUBSCRIBE-NOTIF= Y? >> >> =20 >> >> =20 >> >> Regards, >> >> Adi Even-Tzur. >> >> =20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 10:13: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 KAA06972; Tue, 9 Nov 2004 10:13:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXhT-00064u-W1; Tue, 09 Nov 2004 10:14:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXUr-000631-Ep; Tue, 09 Nov 2004 10:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXNX-0004MU-Cu for simple@megatron.ietf.org; Tue, 09 Nov 2004 09:53: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 JAA04104 for ; Tue, 9 Nov 2004 09:53:49 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXOH-0005Zl-SE for simple@ietf.org; Tue, 09 Nov 2004 09:54:39 -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 iA9ErlF06057; Tue, 9 Nov 2004 16:53:47 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 16:51:51 +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 iA9EppVh029827; Tue, 9 Nov 2004 16:51:51 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 006go4gs; Tue, 09 Nov 2004 16:51:35 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 iA9EpPS03145; Tue, 9 Nov 2004 16:51:25 +0200 (EET) Received: from [130.129.134.192] ([10.241.59.43]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 16:51:24 +0200 Message-ID: <4190D96A.50102@nokia.com> Date: Tue, 09 Nov 2004 09:51:22 -0500 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Adi Even-Tzur Subject: Re: [Simple] PUBLISH identifiers References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 09 Nov 2004 14:51:25.0041 (UTC) FILETIME=[95CF5610:01C4C66B] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int2.ntc.nokia.com id iA9EpPS03145 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Inline. ext Adi Even-Tzur wrote: > Hi, >=20 >=20 >=20 > According to draft-ietf-sip-publish-04.txt, section 4.1, the PUBLISH > identifiers are Request-URI, event *type*, and (optionally) an >=20 > entity-tag. Right. By the way, PUBLISH is now RFC 3903. > RFC 3265, section 7.2.1 refers to the identifiers of SUBSCRIBE > request and includes also the "id" parameter: " An "Event" header > containing an "id" >=20 > parameter never matches an "Event" header without an "id" parameter." >=20 > My question is regarding PUBLISH identifiers =96 >=20 > Is the "id" parameter of the event header should be a differentiator > also for PUBLISH, the same as it define in rfc3265 for > SUBSCRIBE-NOTIFY? No, the "id" parameter means nothing in PUBLISH. It is actually very specific to SUBSCRIBE-NOTIFY, and related to how several subscriptions=20 can be multiplexed over a single subscription dialog. Such a thing does=20 not exist for PUBLISH. Cheers, Aki >=20 >=20 >=20 >=20 >=20 > Regards, >=20 > Adi Even-Tzur. >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 >=20 > _______________________________________________ Simple mailing list=20 > 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 Nov 9 10:14:31 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 KAA07071; Tue, 9 Nov 2004 10:14:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXiK-00066A-4C; Tue, 09 Nov 2004 10:15:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXVM-0006MU-0S; Tue, 09 Nov 2004 10:01:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXP2-0004V1-Tw for simple@megatron.ietf.org; Tue, 09 Nov 2004 09:55: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 JAA04325 for ; Tue, 9 Nov 2004 09:55:22 -0500 (EST) Received: from il-tlv-smtpgateway.comverse.com ([192.118.48.242] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXPn-0005c5-Nu for simple@ietf.org; Tue, 09 Nov 2004 09:56:12 -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 iA9Ew7lm031354 for ; Tue, 9 Nov 2004 16:58:07 +0200 Received: from il-tlv-mail02.comverse.com ([10.115.242.26]) by il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Nov 2004 16:55:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Nov 2004 16:55:21 +0200 Message-ID: <522B9797154BD549B17BA4EAF1DF200C108288@il-tlv-mail02.comverse.com> Thread-Topic: retrieve resource path from RLS Thread-Index: AcTGbCJ7XZnhRXB/TRS9NuSp5crhlw== From: "Nevo Oded" To: X-OriginalArrivalTime: 09 Nov 2004 14:55:21.0529 (UTC) FILETIME=[22C48A90:01C4C66C] X-Spam-Score: 0.5 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Simple] retrieve resource path from RLS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644118560==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 This is a multi-part message in MIME format. --===============1644118560== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C66C.229A7565" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C66C.229A7565 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi=20 How does a UE/DM can retrieve the path of its resource list (e.g. some contact list) in the RLS. I know that when a UE/WATCHER subscribe to XCAP changes in its resource list the path will be retrieved in the NOTIFY returned from the = RLS and will be set to the "uri" attribute of the xml doc (of the NOTIFY = body).=20 Is there any other way or should a UE always needs to subscribe for = changes in its RL in order to get the list path so he can set changes and view via XCAP His RL. 10x Oded ------_=_NextPart_001_01C4C66C.229A7565 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable retrieve resource path from RLS

Hi =

How does = a UE/DM can retrieve the path of its resource list (e.g. = some

contact = list) in the RLS.

I know = that when a UE/WATCHER subscribe to XCAP changes in = its

resource = list the path will be retrieved in the NOTIFY returned from the = RLS

and will = be set to the "uri" attribute of the xml doc (of the NOTIFY = body).

Is there = any other way or should a UE always needs to subscribe for changes in = its

RL in = order to get the list path so he can set changes and view via = XCAP

His = RL.

10x = Oded

------_=_NextPart_001_01C4C66C.229A7565-- --===============1644118560== 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 --===============1644118560==-- From simple-bounces@ietf.org Tue Nov 9 10:21: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 KAA08066; Tue, 9 Nov 2004 10:21:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXop-0006FP-3Y; Tue, 09 Nov 2004 10:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXeT-00031c-1a; Tue, 09 Nov 2004 10:11:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXTu-0005cv-BY for simple@megatron.ietf.org; Tue, 09 Nov 2004 10:00: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 KAA04854 for ; Tue, 9 Nov 2004 10:00: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 1CRXUf-0005ky-9K for simple@ietf.org; Tue, 09 Nov 2004 10:01:13 -0500 Received: from [130.129.133.194] ([130.129.133.194]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iA9ExF4s034483 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 9 Nov 2004 08:59:17 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <4190D94C.8010801@cisco.com> References: <4190D94C.8010801@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Simple] PUBLISH identifiers Date: Tue, 9 Nov 2004 08:59:21 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, Adi Even-Tzur X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable For folks with non-fixed width fonts, Paul points out that I should have said Publish does _not_ involve a dialog. RjS On Nov 9, 2004, at 8:50 AM, Paul Kyzivat wrote: > > > Robert Sparks wrote: >> That's a good question. >> The parameter exists in 3265 to differentiate multiple subscriptions >> to the same Event in the same dialog. Publish does involve a dialog, > ^ > not > >> so the presence or absence of an id parameter (with any syntactically >> valid value) will have no effect on the processing of that Publish. > > The statement is valid with the correction, so I guess this was just a=20= > typo. > > Paul > >> 3903 doesn't talk about that parameter at all. We should queue up >> a clarification that the only part of the Event header field that=20 >> affects >> Publish processing is the event-type field. >> RjS >> On Nov 9, 2004, at 7:04 AM, Adi Even-Tzur wrote: >>> Hi, >>> >>> >>> According to draft-ietf-sip-publish-04.txt, section 4.1, the PUBLISH=20= >>> identifiers are Request-URI, event type, and (optionally) an >>> >>> entity-tag. >>> >>> >>> RFC 3265, section 7.2.1 refers to the identifiers of SUBSCRIBE=20 >>> request and includes also the "id" parameter: " An "Event" header=20 >>> containing an "id" >>> >>> parameter never matches an "Event" header without an "id" = parameter." >>> >>> >>> My question is regarding PUBLISH identifiers =96 >>> >>> Is the "id" parameter of the event header should be a=20 >>> differentiator also for PUBLISH, the same as it define in rfc3265=20 >>> for SUBSCRIBE-NOTIFY? >>> >>> >>> >>> Regards, >>> >>> Adi Even-Tzur. >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 14:28:58 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 OAA03523; Tue, 9 Nov 2004 14:28:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbgc-0004Is-GU; Tue, 09 Nov 2004 14:29:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbbt-00023e-1J; Tue, 09 Nov 2004 14:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbXO-0001UL-1H for simple@megatron.ietf.org; Tue, 09 Nov 2004 14:20: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 OAA02991 for ; Tue, 9 Nov 2004 14:20:16 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbYA-00049y-RN for simple@ietf.org; Tue, 09 Nov 2004 14:21:08 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9JK5E02253; Tue, 9 Nov 2004 21:20:05 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 21:21:13 +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 iA9JLDp4004398; Tue, 9 Nov 2004 21:21:13 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ONFEHo; Tue, 09 Nov 2004 21:21:13 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA9JJua23078; Tue, 9 Nov 2004 21:19:56 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 21:19:57 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 21:19:55 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Question about extending mood in rpids-04 Date: Tue, 9 Nov 2004 21:19:55 +0200 Message-ID: Thread-Topic: [Simple] Question about extending mood in rpids-04 Thread-Index: AcTGYwpxM1/8wKk/RoansC/siEFOMAABSdPg To: X-OriginalArrivalTime: 09 Nov 2004 19:19:55.0861 (UTC) FILETIME=[189B6050:01C4C691] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, hgs@cs.columbia.edu, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable =20 > > Now what if the receiver of these documents doesn't understand > > the ext namespace? In both cases it ignores the "ext" namespace > > and validates rest of it against the "car". I am not sure if > > there are any cases where validator would need to know that > > elements from a namespace it doesn't understand belong to a > > particular substitutionGroup. Can you point out any? >=20 > I'm not sure the difference matters much, but when the extension is=20 > introduced via the ##other mechanism, if the application understands=20 > then it knows that satisfies the schema even without=20 > knowledge of ext. But with the substitution group it has no=20 > way to know=20 > whether the usage of satisfies the schema. For a validator it should not matter if ext is valid or not. It doesn't = understand it and it should be completely insignificant what is inside = that particular extension. We could have similar situation even using ##other. We could have Now, entity that doesn't understand ext would have no idea that = has no definition.=20 - Mikko > Paul >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 9 16:36: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 QAA15533; Tue, 9 Nov 2004 16:36:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdfn-0007Kp-Cn; Tue, 09 Nov 2004 16:37:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdXQ-00053a-Td; Tue, 09 Nov 2004 16:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdR4-0003Gp-Kw for simple@megatron.ietf.org; Tue, 09 Nov 2004 16:21: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 QAA14109 for ; Tue, 9 Nov 2004 16:21:51 -0500 (EST) Received: from 206-169-193-40.gen.twtelecom.net ([206.169.193.40] helo=ProgressiveComputingLLC.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdRt-0006zm-D7 for simple@ietf.org; Tue, 09 Nov 2004 16:22:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Nov 2004 13:21:22 -0800 Message-ID: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02213EA0@svr-exc.domain.com> Thread-Topic: TCP in SDP Thread-Index: AcTGog/exfyyeNRVRlmdBr/RDhTvmA== From: "Thomas Gal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Simple] TCP in SDP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1693047466==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a --===============1693047466== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gd2Ugbm90aWNlZCB0aGUgbWlzc2luZyBwYXJhbWV0ZXIgaW4gYW5vdGhlciBncm91cA0KIA0K aHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tbXVzaWMvY3VycmVudC9tc2cw Mjg4MC5odG1sDQogDQpidXQgSSBzdWJtaXR0aXRlZCBpdCBhbmQgb25lIHdheSBvciBhbm90aGVy IGl0IGhhcyBiZWVuIGFkZGVkIGFuZCBpcyBjb3JyZWN0DQogDQpodHRwOi8vd3d3LmlhbmEub3Jn L2Fzc2lnbm1lbnRzL3NkcC1wYXJhbWV0ZXJzDQogDQpUaGlzIGlzIGluIHJlZmVyZW5jZSB0byB0 aGUgY3VycmVudGx5IG9jY3VyaW5nIFNJTVBMRSBtZWV0aW5nIGRpc2N1c3Npb24uDQogDQpUaG9t YXMgR2FsDQogDQpMZWFkIFByb3RvY29sIEVuZ2luZWVyDQpMdW1lblZveCBMTEMNCjM2MTUgS2Vh cm55IFZpbGxhIFJkDQpTYW4gRGllZ28sIENBIDkyMTE3DQogDQp0aG9tYXNnYWxAbHVtZW52b3gu Y29tDQo4NzctOTc3LTA3MDcgc2F5ICJ0aG9tYXMgZ2FsIg0K --===============1693047466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1693047466==-- From simple-bounces@ietf.org Tue Nov 9 17:52: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 RAA24134; Tue, 9 Nov 2004 17:52:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRerO-0000uv-4e; Tue, 09 Nov 2004 17:53:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRelJ-0006A0-Af; Tue, 09 Nov 2004 17:46:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReaT-0003QP-D9 for simple@megatron.ietf.org; Tue, 09 Nov 2004 17:35: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 RAA22503 for ; Tue, 9 Nov 2004 17:35:38 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReb6-0000TT-VN for simple@ietf.org; Tue, 09 Nov 2004 17:36:33 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA9MZQh5028684 for ; Tue, 9 Nov 2004 23:35:26 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 23:35:26 +0100 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHLPGRBT; Tue, 9 Nov 2004 23:35:26 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Nov 2004 23:35:26 +0100 Message-ID: <6F936E2F8E16234BA8D88B2EE83383320759A1BA@esealnt912.al.sw.ericsson.se> X-Sybari-Trust: 6de7389b bfd556f1 50e925df 00000139 From: "Atle Monrad (GR/ETO)" To: "'Aki Niemi'" , SIMPLE WG Subject: RE: [Simple] New partial publish draft Date: Tue, 9 Nov 2004 23:35:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Nov 2004 22:35:26.0536 (UTC) FILETIME=[68A25480:01C4C6AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi a few comments: 1. As we have two terms, full and partial publication, I would prefer that the initial publication is full followed by partial (close the 1st open issue). 2. I do not see any problem to 'mix' the full and partial publish with the text as it is written. If this is the case, I would prefer that we spell it clearly out. If not, we have to make that clear as well. 3. I do not see more text needed for the compositor either (2nd open item). br Atle Monrad Ericsson Mobile Platform -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf Of Aki Niemi Sent: 28. oktober 2004 04:35 To: SIMPLE WG Subject: [Simple] New partial publish draft All, A new version of the partial publication draft is available. Until it appears in the archives, a copy has been placed at: http://people.nokia.net/~aki/drafts/draft-ietf-simple-partial-publish-01.txt Changes: - This version uses the updated partial-format, meaning that rather than working on a per tuple basis, the PUA can make finer-grained granular updates to the presence information. - Initial publications now contain full-state using the normal PIDF format. Clients will also fall back to PIDF if a partial update receives a 415 error response. Comments most welcome. Cheers, Aki _______________________________________________ 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 Nov 10 01:57: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 BAA01962; Wed, 10 Nov 2004 01:57:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRmQh-0001x0-NT; Wed, 10 Nov 2004 01:58:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRmOW-0003rl-GF; Wed, 10 Nov 2004 01:55:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRmNW-0003kt-NM for simple@megatron.ietf.org; Wed, 10 Nov 2004 01:54: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 BAA01805 for ; Wed, 10 Nov 2004 01:54:49 -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 1CRmOP-0001uM-VJ for simple@ietf.org; Wed, 10 Nov 2004 01:55:47 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2004 23:08:08 -0800 X-BrightmailFiltered: true 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 iAA6sAcj017101; Tue, 9 Nov 2004 22:54:14 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn4-1402.cisco.com [10.21.85.121]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFQ41521; Tue, 9 Nov 2004 22:54:09 -0800 (PST) Message-ID: <4191BB11.9060606@cisco.com> Date: Wed, 10 Nov 2004 01:54:09 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: <445C57B81208C24EAD99F2944DBB9D2908FE39CE@blnss10a.bln1.siemens.de> <4188DB48.4040104@cs.columbia.edu> In-Reply-To: <4188DB48.4040104@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Simple WG , Boehmer Bernhard ICM Berlin X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit I agree with Henning here; I don't see how the layer of indirection solves anything. -Jonathan R. Henning Schulzrinne wrote: > Boehmer Bernhard ICM Berlin wrote: > >> Hi Henning, >> service ID: certainly indirection has its drawbacks; >> in this case the main question is whether the higher >> flexibility of indirection outweighs the overhead >> introduced with that. Actually, the whole XML schema >> architecture is using it heavily (this becomes obvious >> to me each time I edit XML schemas without being connected >> to the Internet...:). > > > While it is easy for a mobile provider to publish a UDDI directory entry > for its limited number of phones, say, it seems much harder for the > average user in a corporate network or using a provider. They will have > to rely on the provider or corporate network to host this information. > Unless you want to rely on web pages for configuration, every new source > of information means that there needs to be authentication, a means to > publish this information and to change it. > > The only advantage of inclusion by reference is space saving. Otherwise, > whatever service description you include by reference can also be > included by value. > > The space saving only matters if the mobile transmits the information. > This seems unlikely, even with inclusion. > > Thus, I'm at a loss to see why adding another protocol machinery for > managing UDDI stores to every PUA or PA adds significant value that > outweighs the complexity incurred. > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 10 02:14: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 CAA16303; Wed, 10 Nov 2004 02:14:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRmh8-0002FN-Bb; Wed, 10 Nov 2004 02:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRme1-000063-96; Wed, 10 Nov 2004 02:11:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRmdk-0008OW-09 for simple@megatron.ietf.org; Wed, 10 Nov 2004 02:11:36 -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 CAA13756 for ; Wed, 10 Nov 2004 02:11:34 -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 1CRmeb-0002Bq-QJ for simple@ietf.org; Wed, 10 Nov 2004 02:12:32 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2004 23:24:52 -0800 X-BrightmailFiltered: true 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 iAA7Avcp027991; Tue, 9 Nov 2004 23:10:58 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn4-1402.cisco.com [10.21.85.121]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFQ42168; Tue, 9 Nov 2004 23:10:56 -0800 (PST) Message-ID: <4191BEFF.2090200@cisco.com> Date: Wed, 10 Nov 2004 02:10:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Question about extending mood in rpids-04 References: <4190CA60.8080106@cisco.com> In-Reply-To: <4190CA60.8080106@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, mikko.lonnfors@nokia.com, hgs@cs.columbia.edu, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit I had always assumed that if the entity validating the document didn't know about the extensions, the validation would proceed as if the unknown elements were part of the substitution group. However, I think that it is important for us to check this with folks who are more familiar with XML... -Jonathan R. Paul Kyzivat wrote: > Response near the end. > > Paul > > mikko.lonnfors@nokia.com wrote: > >>> mikko.lonnfors@nokia.com wrote: >>> >>>> >>>> >>>>> I'm wondering about the future proofness when using the >>>> >>>> >>> substitution >>> >>>>> groups. If the recipient is doing document validation, but doesn't >>>>> possess the extension schema, will it be able to validate the >>>>> document. >>>> >>>> >>>> >>>> As far as I understand, yes it can. >>> >>> >>> Can you explain? If I receive a document that has an element I don't >>> understand, how can I tell it is an instance of a particular >>> substitution group if that is what is required for the document to be >>> valid? >> >> >> >> Lets take an example. We can have two schema definitions: >> >> 1) using substitutiongroups >> >> targetnamespace="car" >> xmlns:tns="car" >> >> >> >> > ref="tns:carmodel" >> maxOccurs="unbounded"/> >> >> >> >> >> >> >> >> >> And if we would define an extension it would look something like >> >> targetnamespace="ext" >> xmlns:tns="ext" >> xmlns:car="car" >> >> >> >> Resulting XML document would be something like: >> >> >> > xmlns:ext="ext"> >> >> >> >> >> 2) using xml ##other extensibility mechanism >> >> >> >> >> >> > processContents="lax" minOccurs="0" >> maxOccurs="unbounded"/> >> >> >> >> And if we would define an extension it would look something like >> >> targetnamespace="ext" >> xmlns:tns="ext" >> xmlns:car="car" >> >> >> >> Resulting XML document would be something like: >> >> >> > xmlns:ext="ext"> >> >> >> >> >> Now what if the receiver of these documents doesn't understand > > > the ext namespace? In both cases it ignores the "ext" namespace > > and validates rest of it against the "car". I am not sure if > > there are any cases where validator would need to know that > > elements from a namespace it doesn't understand belong to a > > particular substitutionGroup. Can you point out any? > > I'm not sure the difference matters much, but when the extension is > introduced via the ##other mechanism, if the application understands > then it knows that satisfies the schema even without > knowledge of ext. But with the substitution group it has no way to know > whether the usage of satisfies the schema. > > Paul > >> Only case I might come up is: >> >> >> > ref="tns:carmodel" >> maxOccurs="1" >> minOccurs="1"/> >> >> >> >> >> and >> >> > xmlns:ext="ext"> >> >> >> >> In this case if I don't understand "ext" I cannot say if > > > really is a member of carmodel substitutionGroup > > but does it matter? I can still say that there is one element > > (as required) but I don't understand it. > >> >> - Mikko >> >>> Paul >>> >>> >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 10 07:24: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 HAA28891; Wed, 10 Nov 2004 07:24:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRrXW-0000DY-3F; Wed, 10 Nov 2004 07:25:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRrSG-0007Zb-7G; Wed, 10 Nov 2004 07:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRrRT-0007Su-3h for simple@megatron.ietf.org; Wed, 10 Nov 2004 07:19: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 HAA28225 for ; Wed, 10 Nov 2004 07:19:13 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRrSP-000075-TL for simple@ietf.org; Wed, 10 Nov 2004 07:20:14 -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 iAACIuv11274; Wed, 10 Nov 2004 14:18:56 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 14:18:32 +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 iAACIW1G005096; Wed, 10 Nov 2004 14:18:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00RohW6F; Wed, 10 Nov 2004 14:18:31 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAACITa17706; Wed, 10 Nov 2004 14:18:29 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 14:18:29 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 14:18:30 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 14:18:28 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Simple] Data model - attempt at summary Date: Wed, 10 Nov 2004 14:18:28 +0200 Message-ID: Thread-Topic: AW: AW: [Simple] Data model - attempt at summary Thread-Index: AcTG81WrC4yB8SMDQhKQHkw7u8NCkAAKmoEQ To: , X-OriginalArrivalTime: 10 Nov 2004 12:18:28.0478 (UTC) FILETIME=[6290B1E0:01C4C71F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, bernhard.boehmer@siemens.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Hi, It would be good if the data model explicitly addressed the issue of how = to describe "proprietary" services in tuples. By "proprietary" I mean in = this case something that can't be expressed with prescaps capabilities. = Of course we can leave it completely open, but I think there would be = some value to have a recommendation how to do this consistently. I still think that there should be this kind of service ID in the tuple = for this purpose with a certain type of registry to avoid overlaps. The = main benefit for this would be the ability to do authorization rules for = this type of proprietary services. Currently it is hard, if those = services use SIP AOR as a contact address, i.e. the contact address = field alone is not enough to pinpoint the tuple describing such a = service. Markus=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 10 November, 2004 08:54 > To: Henning Schulzrinne > Cc: Simple WG; Boehmer Bernhard ICM Berlin > Subject: Re: AW: AW: [Simple] Data model - attempt at summary >=20 >=20 > I agree with Henning here; I don't see how the layer of indirection=20 > solves anything. >=20 > -Jonathan R. >=20 > Henning Schulzrinne wrote: >=20 > > Boehmer Bernhard ICM Berlin wrote: > >=20 > >> Hi Henning, > >> service ID: certainly indirection has its drawbacks; > >> in this case the main question is whether the higher > >> flexibility of indirection outweighs the overhead > >> introduced with that. Actually, the whole XML schema > >> architecture is using it heavily (this becomes obvious > >> to me each time I edit XML schemas without being connected > >> to the Internet...:). > >=20 > >=20 > > While it is easy for a mobile provider to publish a UDDI=20 > directory entry=20 > > for its limited number of phones, say, it seems much harder for the=20 > > average user in a corporate network or using a provider.=20 > They will have=20 > > to rely on the provider or corporate network to host this=20 > information.=20 > > Unless you want to rely on web pages for configuration,=20 > every new source=20 > > of information means that there needs to be authentication,=20 > a means to=20 > > publish this information and to change it. > >=20 > > The only advantage of inclusion by reference is space=20 > saving. Otherwise,=20 > > whatever service description you include by reference can also be=20 > > included by value. > >=20 > > The space saving only matters if the mobile transmits the=20 > information.=20 > > This seems unlikely, even with inclusion. > >=20 > > Thus, I'm at a loss to see why adding another protocol=20 > machinery for=20 > > managing UDDI stores to every PUA or PA adds significant value that=20 > > outweighs the complexity incurred. > >=20 > > Henning > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 10 07:39: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 HAA00815; Wed, 10 Nov 2004 07:39:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRrli-0000YM-K1; Wed, 10 Nov 2004 07:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRrge-00014r-92; Wed, 10 Nov 2004 07:34:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRrgO-0000yH-OU for simple@megatron.ietf.org; Wed, 10 Nov 2004 07:34:40 -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 HAA00177 for ; Wed, 10 Nov 2004 07:34:39 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRrhL-0000Rc-RJ for simple@ietf.org; Wed, 10 Nov 2004 07:35:40 -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 iAACYYv05885; Wed, 10 Nov 2004 14:34:35 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 14:34:14 +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 iAACYERm009067; Wed, 10 Nov 2004 14:34:14 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 005WPkgw; Wed, 10 Nov 2004 14:33:50 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 iAACXiS18830; Wed, 10 Nov 2004 14:33:44 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 14:33:44 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 14:33:44 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2004 14:33:45 +0200 Message-ID: Thread-Topic: [Simple] Question about extending mood in rpids-04 Thread-Index: AcTG9SvigcV9WLhKRvymxyj693h7wQAKkWKg To: X-OriginalArrivalTime: 10 Nov 2004 12:33:44.0824 (UTC) FILETIME=[84BFFF80:01C4C721] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: [Simple] Presence auth rules: authenticated condition and exceptions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Hi, I know this has been discussed several times, but I'd still like to = propose it once again. I believe the conclusion of yesterday's SIMPLE meeting was that there = will be a new condition for pres auth rules called authenticated, which = would be fulfilled by any request that came from an authenticated = source. I would like to include the exception clause for that, which = would allow "blacklisting" _within_ the scope of authenticated = identities. Currently this is only allowed within a single domain. While = such blacklisting would be pretty useless in systems where it is easy to = generate new authenticated identities, it would be valuable in more = restricted systems where there is certain cost/policy for obtaining = identities. I understand that once more and more domains are = interconnected to the system, the easiness of getting a new identity is = based on the "weakest link", and thus it is hard to maintain the = restrictiveness for large multi-domain systems. Nevertheless, there is = strong user expectation for this type of feature.=20 Thanks, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 10 08:38: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 IAA07051; Wed, 10 Nov 2004 08:38:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsh8-00025J-MD; Wed, 10 Nov 2004 08:39:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRscF-0000AK-TO; Wed, 10 Nov 2004 08:34:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsXy-00089T-NS for simple@megatron.ietf.org; Wed, 10 Nov 2004 08:30: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 IAA06338 for ; Wed, 10 Nov 2004 08:30:01 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsYv-0001vr-Bn for simple@ietf.org; Wed, 10 Nov 2004 08:31:02 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 10 Nov 2004 08:29:30 -0500 X-BrightmailFiltered: true 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 iAADTRR5020826; Wed, 10 Nov 2004 08:29:28 -0500 (EST) Received: from cisco.com (rtp-vpn2-393.cisco.com [10.82.241.137]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX91844; Wed, 10 Nov 2004 08:29:26 -0500 (EST) Message-ID: <419217B5.6090903@cisco.com> Date: Wed, 10 Nov 2004 08:29:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Question about extending mood in rpids-04 References: <4190CA60.8080106@cisco.com> <4191BEFF.2090200@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, mikko.lonnfors@nokia.com, hgs@cs.columbia.edu, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit I am only asking the question as one who has no formal knowledge of xml. Whatever is right with xml is fine with me. Paul Jonathan Rosenberg wrote: > I had always assumed that if the entity validating the document didn't > know about the extensions, the validation would proceed as if the > unknown elements were part of the substitution group. However, I think > that it is important for us to check this with folks who are more > familiar with XML... > > -Jonathan R. > > Paul Kyzivat wrote: > >> Response near the end. >> >> Paul >> >> mikko.lonnfors@nokia.com wrote: >> >>>> mikko.lonnfors@nokia.com wrote: >>>> >>>>> >>>>> >>>>>> I'm wondering about the future proofness when using the >>>>> >>>>> >>>>> >>>> substitution >>>> >>>>>> groups. If the recipient is doing document validation, but doesn't >>>>>> possess the extension schema, will it be able to validate the >>>>>> document. >>>>> >>>>> >>>>> >>>>> >>>>> As far as I understand, yes it can. >>>> >>>> >>>> >>>> Can you explain? If I receive a document that has an element I don't >>>> understand, how can I tell it is an instance of a particular >>>> substitution group if that is what is required for the document to >>>> be valid? >>> >>> >>> >>> >>> Lets take an example. We can have two schema definitions: >>> >>> 1) using substitutiongroups >>> >>> targetnamespace="car" >>> xmlns:tns="car" >>> >>> >>> >>> >> ref="tns:carmodel" >>> maxOccurs="unbounded"/> >>> >>> >>> >>> >>> >>> >>> >>> >>> And if we would define an extension it would look something like >>> >>> targetnamespace="ext" >>> xmlns:tns="ext" >>> xmlns:car="car" >>> >>> >>> >>> Resulting XML document would be something like: >>> >>> >>> >> xmlns:ext="ext"> >>> >>> >>> >>> >>> 2) using xml ##other extensibility mechanism >>> >>> >>> >>> >>> >>> >> processContents="lax" minOccurs="0" >>> maxOccurs="unbounded"/> >>> >>> >>> And if we would define an extension it would look something like >>> >>> targetnamespace="ext" >>> xmlns:tns="ext" >>> xmlns:car="car" >>> >>> >>> >>> Resulting XML document would be something like: >>> >>> >>> >> xmlns:ext="ext"> >>> >>> >>> >>> >>> Now what if the receiver of these documents doesn't understand >> >> >> > the ext namespace? In both cases it ignores the "ext" namespace >> > and validates rest of it against the "car". I am not sure if >> > there are any cases where validator would need to know that >> > elements from a namespace it doesn't understand belong to a >> > particular substitutionGroup. Can you point out any? >> >> I'm not sure the difference matters much, but when the extension is >> introduced via the ##other mechanism, if the application understands >> then it knows that satisfies the schema even without >> knowledge of ext. But with the substitution group it has no way to >> know whether the usage of satisfies the schema. >> >> Paul >> >>> Only case I might come up is: >>> >>> >>> >> ref="tns:carmodel" >>> maxOccurs="1" >>> minOccurs="1"/> >>> >>> >>> >>> >>> and >>> >>> >> xmlns:ext="ext"> >>> >>> >>> >>> In this case if I don't understand "ext" I cannot say if >> >> >> > really is a member of carmodel substitutionGroup >> > but does it matter? I can still say that there is one element >> > (as required) but I don't understand it. >> >>> >>> - Mikko >>> >>>> Paul >>>> >>>> >>> >>> >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 10 08:44: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 IAA07588; Wed, 10 Nov 2004 08:44:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsn9-0002CE-5Q; Wed, 10 Nov 2004 08:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsj7-0001Vw-Rq; Wed, 10 Nov 2004 08:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRshS-0001Hg-UF for simple@megatron.ietf.org; Wed, 10 Nov 2004 08:39: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 IAA07164 for ; Wed, 10 Nov 2004 08:39:49 -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 1CRsiP-00026G-ML for simple@ietf.org; Wed, 10 Nov 2004 08:40:51 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2004 05:53:11 -0800 X-BrightmailFiltered: true 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 iAADdEcp024051; Wed, 10 Nov 2004 05:39:15 -0800 (PST) Received: from cisco.com (rtp-vpn2-393.cisco.com [10.82.241.137]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX92320; Wed, 10 Nov 2004 08:39:13 -0500 (EST) Message-ID: <41921A01.5090303@cisco.com> Date: Wed, 10 Nov 2004 08:39:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: bernhard.boehmer@siemens.com, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Markus, To describe a service that can't be described with prescaps, you just need to use some other (perhaps proprietary) extension entitites within tuple or status. I had wanted the callerprefs extension mechanism mapped over to prescaps in order to make extensions to presence as simple as extensions to callee caps, but that got lost along the way. Nevertheless I don't think it is very hard to define your own xml schema for this purpose. Paul Markus.Isomaki@nokia.com wrote: > Hi, > > It would be good if the data model explicitly addressed the issue of how to describe "proprietary" services in tuples. By "proprietary" I mean in this case something that can't be expressed with prescaps capabilities. Of course we can leave it completely open, but I think there would be some value to have a recommendation how to do this consistently. > > I still think that there should be this kind of service ID in the tuple for this purpose with a certain type of registry to avoid overlaps. The main benefit for this would be the ability to do authorization rules for this type of proprietary services. Currently it is hard, if those services use SIP AOR as a contact address, i.e. the contact address field alone is not enough to pinpoint the tuple describing such a service. > Markus > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Jonathan Rosenberg >>Sent: 10 November, 2004 08:54 >>To: Henning Schulzrinne >>Cc: Simple WG; Boehmer Bernhard ICM Berlin >>Subject: Re: AW: AW: [Simple] Data model - attempt at summary >> >> >>I agree with Henning here; I don't see how the layer of indirection >>solves anything. >> >>-Jonathan R. >> >>Henning Schulzrinne wrote: >> >> >>>Boehmer Bernhard ICM Berlin wrote: >>> >>> >>>>Hi Henning, >>>>service ID: certainly indirection has its drawbacks; >>>>in this case the main question is whether the higher >>>>flexibility of indirection outweighs the overhead >>>>introduced with that. Actually, the whole XML schema >>>>architecture is using it heavily (this becomes obvious >>>>to me each time I edit XML schemas without being connected >>>>to the Internet...:). >>> >>> >>>While it is easy for a mobile provider to publish a UDDI >> >>directory entry >> >>>for its limited number of phones, say, it seems much harder for the >>>average user in a corporate network or using a provider. >> >>They will have >> >>>to rely on the provider or corporate network to host this >> >>information. >> >>>Unless you want to rely on web pages for configuration, >> >>every new source >> >>>of information means that there needs to be authentication, >> >>a means to >> >>>publish this information and to change it. >>> >>>The only advantage of inclusion by reference is space >> >>saving. Otherwise, >> >>>whatever service description you include by reference can also be >>>included by value. >>> >>>The space saving only matters if the mobile transmits the >> >>information. >> >>>This seems unlikely, even with inclusion. >>> >>>Thus, I'm at a loss to see why adding another protocol >> >>machinery for >> >>>managing UDDI stores to every PUA or PA adds significant value that >>>outweighs the complexity incurred. >>> >>>Henning >>> >>>_______________________________________________ >>>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 >> > > > _______________________________________________ > 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 Nov 10 10:57: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 KAA23569; Wed, 10 Nov 2004 10:57:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRurf-0005ix-7z; Wed, 10 Nov 2004 10:58:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRudg-00071N-2V; Wed, 10 Nov 2004 10:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuZO-0006GB-RN for simple@megatron.ietf.org; Wed, 10 Nov 2004 10:39:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21266 for ; Wed, 10 Nov 2004 10:39:35 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuaJ-0005Dp-Rn for simple@ietf.org; Wed, 10 Nov 2004 10:40:39 -0500 Received: from [130.129.132.245] ([130.129.132.245]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAAFdPvj053557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Nov 2004 09:39:26 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4192362E.40904@nostrum.com> Date: Wed, 10 Nov 2004 09:39:26 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org X-Enigmail-Version: 0.86.1.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: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: 413 response needed? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit So, I'm looking at the case where I have a client that wants to say, "I want to keep getting your messages on this session, and I don't want to suppress your sending of any particular data type for this session, but please stop sending this particular message." (More concretely: I don't want to block all future attempts to send video/mpeg4, but please stop sending me your copy of The Matrix.) I picked through all the MSRP status codes, and couldn't find one that allows me to do this. It seems to me that addition of a 413 status code which means, "stop this one message" would accomplish this task. Thoughts? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 10 21:34: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 VAA03267; Wed, 10 Nov 2004 21:34:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4oF-0005wn-Ck; Wed, 10 Nov 2004 21:35:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4f9-0003Qn-Ef; Wed, 10 Nov 2004 21:26:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4Ym-0002Br-OV for simple@megatron.ietf.org; Wed, 10 Nov 2004 21:19:40 -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 VAA02191 for ; Wed, 10 Nov 2004 21:19:38 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4Zq-0005eA-TF for simple@ietf.org; Wed, 10 Nov 2004 21:20:47 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id iAB24A9L000145; Wed, 10 Nov 2004 21:04:11 -0500 (EST) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 21:01:15 -0500 Message-ID: From: Eric Burger To: David R Oran Subject: RE: MSRP: Are REPORTs per-chunk or per-message? (was Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs ) Date: Wed, 10 Nov 2004 21:01:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Even though I would be thrilled if this stuff came out, because the value/pain ratio is really low, I had a bizarre thought for a 4/1/2005 RFC that relies on chunking, byte ranges, and retransmission of missing chunks. More news after I finish my comprehensive exam :) > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Friday, October 08, 2004 10:01 AM > To: Ben Campbell > Cc: Cullen Jennings; Rohan Mahy; Adam Roach; Aki Niemi; Paul Kyzivat; > Simple WG > Subject: Re: MSRP: Are REPORTs per-chunk or per-message? (was Re: > [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges > in REPORTs) > > > Based on this exchange, I suggest we rename the protocol to > MHRFTPWCBYFIM. > > (Multi hop recoverable file transfer protocol which could be used for > instant messaging). > > I am getting creeping featurism vibes here, guys... > > Dave. > > On Oct 7, 2004, at 11:07 PM, Ben Campbell wrote: > > > > > On Oct 5, 2004, at 3:58 PM, Paul Kyzivat wrote: > > > >> > >> > >> Ben Campbell wrote: > >>> On Oct 5, 2004, at 7:09 AM, Aki Niemi wrote: > >>>> On Sat, 2004-10-02 at 01:16, ext Ben Campbell wrote: > >>>> > >>>>> Oops, I just realized I missed one of Paul's comments. > >>>>> > >>>>> Paul suggests there is no value saying what part of a message > >>>>> fails, > >>>>> only that the whole message fails. I disagree. If a > sender learns > >>>>> that > >>>>> a particular byte-range failed, it may be able to send > a new chunk > >>>>> containing that byte range. > >>>> > >>>> > >>>> I don't get this. We have a protocol that runs on top of a TCP > >>>> connection, or a chain of TCP connections. The only way > a chunk can > >>>> ever > >>>> get lost without anyone noticing it hop-by-hop is if > someone's input > >>>> buffer or output buffer is seriously leaking bits. Do we really > >>>> need to > >>>> design around that hypothetical condition? > >>> On reflection, I think I am mostly convinced that you are > right. The > >>> only case I can think of is when you successfully send a > bunch of > >>> chunks, the session fails, you signal a new session, and > attempt to > >>> resend the content. One could be saved the task of > sending all the > >>> parts that had already been delivered. But I think I > agree that this > >>> benefit is not worth the additional complexity and statefulness > >>> necessary to make it work. > >> > >> The significant case now occurs to me: > >> > >> - we are sending that 7gb Lord of the Rings as one message, > >> and part way through the tcp connection fails somewhere > >> along the way. (Maybe a relay crashed.) > >> > >> - it would be good not to have to retransmit the part that > >> got there. Would prefer to establish a replacement > >> session and just send the part we aren't sure was received. > >> > >> To make this work, the sender needs to have received > success reports > >> for fragments. Maybe this is worth supporting them. > >> > >> Of course the recipient is still free to just send a > single success > >> report at the end, or it can periodically send reports for > arbitrary > >> byte ranges that it has received ok. These wouldn't have to > >> correspond to the actual chunking of the message. One > could simple be > >> sent every so often, reflecting what has been received to date. > >> > >> So I think I have talked myself back into liking this for success > >> reports. > >> > >> I'm still not convinced about the value in failure reports, but if > >> the range can be there for one then why not the other? > >> > > > > I had a conversation with Cullen, where he expressed the > same opinion > > for failure reports. Imagine, in your LoTR example, you > were using a > > relay, and it has a transport failure between itself and > the next hop. > > It sends you one or more failure reports for the chunks for > which it > > could not confirm delivery. You establish a new session, > and continue; > > resending the failed chunks. > > > > I'd like to close on this quickly, so I offer the following > questions > > to anyone who cares. I would appreciate opinions asap, so I can get > > this into the next revision. > > > > 1) Should failure reports be sent per chunk or per complete > message? > > (I think it is per chunk.) > > > > 2) Should success reports be sent per chunk or per complete > message? > > Note that, if we send them per-chunk, then the sender must > accumulate > > 1 or more reports covering all the bytes in the message > before it can > > consider the message successful. These reports may or may not > > correspond one-to-one with the chunks it sent, as a relay may > > re-chunk. > > > > (Again, I vote per-chunk.) > > > > 3) Do we need to say anything about how long the _receiver_ > holds onto > > the chunks of an incomplete message in hopes any remaining chunks > > arrive? In particular, do we need to talk about this for holding > > chunks after a session fails, in case the sender establishes a new > > session and sends the remaining chunks? > > > > (I vote that we say no more than we already did in 08 concerning > > re-sending chunks on new sessions.) > > > > 4) Do we need to enable the receiver to send a failure report about > > _missing_ chunks? This does not make sense with success reports > > requested, but might make sense when only failure reports are > > requested. > > > > (I vote no, as I think that, if failure reports are requested, any > > such failure will be discovered and reported by some > up-stream device > > except in the most rare of corner cases. The exception is when the > > sender does not actually send all the chunks; but if that > happens it > > doesn not need to be told about it by another device.) > > > > > >> Paul > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@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 Thu Nov 11 04:33: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 EAA17989; Thu, 11 Nov 2004 04:33:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSBLT-00058M-Dd; Thu, 11 Nov 2004 04:34:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSBIE-0000q3-FP; Thu, 11 Nov 2004 04:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSBHU-0000gB-Qi for simple@megatron.ietf.org; Thu, 11 Nov 2004 04:30: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 EAA17597 for ; Thu, 11 Nov 2004 04:30:14 -0500 (EST) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSBIc-00054O-Ls for simple@ietf.org; Thu, 11 Nov 2004 04:31:27 -0500 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id iAB9T2dr025423; Thu, 11 Nov 2004 10:29:02 +0100 (MET) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id iAB9SvDm012838; Thu, 11 Nov 2004 10:28:57 +0100 (MET) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Nov 2004 10:28:57 +0100 Message-ID: <445C57B81208C24EAD99F2944DBB9D2908FE3A2B@blnss10a.bln1.siemens.de> From: Boehmer Bernhard Com Berlin To: "'Jonathan Rosenberg'" , Henning Schulzrinne Subject: RE: AW: AW: [Simple] Data model - attempt at summary Date: Thu, 11 Nov 2004 10:28:51 +0100 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.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "'markus.isomaki@nokia.com'" , Simple WG , Boehmer Bernhard Com Berlin X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Anything is a hard word ... There are different issues which must be addressed: - the description of services; I'm still not convinced that the description via prefs is applicable to services in general. Pointing to a description document is a way to address that. A more direct poiting to such a doc would be definitly nicer if possible. - the inclusion of proprietary services: This is related to to the first point. - the definition of a unique service ID which is well known. The tmodel approach is a proposal to generate and publish such an ID. I would certainly appreciate other solutions are avoiding at least one of the two levels of indirection. Regards Bernhard -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Mittwoch, 10. November 2004 07:54 To: Henning Schulzrinne Cc: Boehmer Bernhard ICM Berlin; Simple WG Subject: Re: AW: AW: [Simple] Data model - attempt at summary I agree with Henning here; I don't see how the layer of indirection solves anything. -Jonathan R. Henning Schulzrinne wrote: > Boehmer Bernhard ICM Berlin wrote: > >> Hi Henning, >> service ID: certainly indirection has its drawbacks; >> in this case the main question is whether the higher >> flexibility of indirection outweighs the overhead >> introduced with that. Actually, the whole XML schema >> architecture is using it heavily (this becomes obvious >> to me each time I edit XML schemas without being connected >> to the Internet...:). > > > While it is easy for a mobile provider to publish a UDDI directory entry > for its limited number of phones, say, it seems much harder for the > average user in a corporate network or using a provider. They will have > to rely on the provider or corporate network to host this information. > Unless you want to rely on web pages for configuration, every new source > of information means that there needs to be authentication, a means to > publish this information and to change it. > > The only advantage of inclusion by reference is space saving. Otherwise, > whatever service description you include by reference can also be > included by value. > > The space saving only matters if the mobile transmits the information. > This seems unlikely, even with inclusion. > > Thus, I'm at a loss to see why adding another protocol machinery for > managing UDDI stores to every PUA or PA adds significant value that > outweighs the complexity incurred. > > Henning > > _______________________________________________ > 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 Thu Nov 11 08:14: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 IAA07367; Thu, 11 Nov 2004 08:14:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSEnJ-0001b6-Hq; Thu, 11 Nov 2004 08:15:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSEl1-0000TD-Vd; Thu, 11 Nov 2004 08:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSEgn-0008NQ-QS for simple@megatron.ietf.org; Thu, 11 Nov 2004 08:08:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06952 for ; Thu, 11 Nov 2004 08:08:36 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSEhx-0001US-Gq for simple@ietf.org; Thu, 11 Nov 2004 08:09: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 iABD8Fv21408; Thu, 11 Nov 2004 15:08:16 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 15:07:26 +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 iABD7QRs004075; Thu, 11 Nov 2004 15:07:26 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Dvl0f6; Thu, 11 Nov 2004 15:07:05 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABD6ua27837; Thu, 11 Nov 2004 15:06:56 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 15:06:47 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 15:06:50 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Simple] Data model - attempt at summary Date: Thu, 11 Nov 2004 15:06:49 +0200 Message-ID: Thread-Topic: AW: AW: [Simple] Data model - attempt at summary Thread-Index: AcTHKsmdr3lZsWVNQoyiym3EVc3w+wAwi1uA To: X-OriginalArrivalTime: 11 Nov 2004 13:06:50.0817 (UTC) FILETIME=[4EE83B10:01C4C7EF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: bernhard.boehmer@siemens.com, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Hi Paul, See inline. Paul Kyzivat wrote: >=20 > Markus, >=20 > To describe a service that can't be described with prescaps, you just=20 > need to use some other (perhaps proprietary) extension=20 > entitites within=20 > tuple or status. > Yes, I understand this is the idea. =20 > I had wanted the callerprefs extension mechanism mapped over=20 > to prescaps=20 > in order to make extensions to presence as simple as extensions to=20 > callee caps, but that got lost along the way. Nevertheless I=20 > don't think=20 > it is very hard to define your own xml schema for this purpose. >=20 It is not hard as such. The problem I would like to address actually = this:=20 The user has service foo that uses SIP to open some media sessions. It = is possible to create capability extensions which make it clear for the = other end that this is foo. However, is it possible for the user to = authorize the service tuple published by foo in some clear way? = Originally I thought class could be used as this type of selector = (although no conflict resolution exist for class values), but it is no = longer supported. Currently the only ways to select tuples in = authorization phase are URI scheme and URI itself. But if we accept the = case that there can be several tuples/services with the same URI, they = become an unseparable unit from authorization point of view. Some sort = of id in the tuples that services/publishers could consistently use = would help, and why not using that then to tell something to the = watchers too. > Paul > Markus=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 11 08:47: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 IAA10403; Thu, 11 Nov 2004 08:47:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSFJx-0002IP-9u; Thu, 11 Nov 2004 08:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSFFd-0005EV-00; Thu, 11 Nov 2004 08:44:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSF72-0003em-QS for simple@megatron.ietf.org; Thu, 11 Nov 2004 08:35: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 IAA09268 for ; Thu, 11 Nov 2004 08:35:43 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSF8D-00023G-8T for simple@ietf.org; Thu, 11 Nov 2004 08:36:57 -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 iABDZUF06166; Thu, 11 Nov 2004 15:35:31 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 15:35:10 +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 iABDZAb4025590; Thu, 11 Nov 2004 15:35:10 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00z6Dh6J; Thu, 11 Nov 2004 15:34:28 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 iABDYSS18114; Thu, 11 Nov 2004 15:34:28 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 15:34:27 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 15:34:27 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Simple] Data model - attempt at summary Date: Thu, 11 Nov 2004 15:34:27 +0200 Message-ID: Thread-Topic: AW: AW: [Simple] Data model - attempt at summary Thread-Index: AcTH0X16pmPYLe13TMWgVA2ZdiaeHgAHgxmQ To: , , X-OriginalArrivalTime: 11 Nov 2004 13:34:27.0818 (UTC) FILETIME=[2A8E84A0:01C4C7F3] X-Spam-Score: 0.3 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Hi, I have thought about this a bit and my current thinking is this: - Prescaps and other decomposed capabilities are good as long as your = application can interoperate with another application which only = supports a subset of your capabilities. In some cases this is clearly = useful, e.g. with different medias. - If you have a proprietary application, which can ONLY work with = another similar app, there is no use in decomposing the capabilities. So = for each this kind of app you just define a single proprietary = capability who is only understood by other similar apps. - This type of proprietary app should be published in a separate tuple = of its own, and actually SHOULD NOT included other capabilities. E.g. = even if the app supported voice, there is no point listing that, if it = can't work with another app that ONLY supports voice but not the = proprietary part. - On the other hand if you have an application which has a certain = proprietary capability, but that is not essential, you can just include = that in the tuple _in addition_ to all other capabilities that you might = have. (So using the example of the proprietary push-to-talk app that I = described some time ago: I think that should just define a single = capability extension, and definitely NOT include voice and half-duplex = capabilities in its tuple to fool a watcher who has half-duplex VoIP to = call.)=20 What is needed is merely a way to be able to define authorization rules, = which can select this type of tuples individually. Currently you can do = this only if you support GRUU. I think this is the main use case for = having some other identifier available for the selection. So maybe the "service ID" as such is not needed after all? Markus =20 > -----Original Message----- > From: ext Boehmer Bernhard Com Berlin > [mailto:bernhard.boehmer@siemens.com] > Sent: 11 November, 2004 11:29 > To: 'Jonathan Rosenberg'; Henning Schulzrinne > Cc: Boehmer Bernhard Com Berlin; Simple WG; Isomaki Markus > (Nokia-TP/Espoo) > Subject: RE: AW: AW: [Simple] Data model - attempt at summary >=20 >=20 > Anything is a hard word ...=20 > There are different issues which must be addressed: >=20 > - the description of services; I'm still not convinced > that the description via prefs is applicable to services > in general. Pointing to a description document is a way > to address that. A more direct poiting to such a doc would > be definitly nicer if possible. > - the inclusion of proprietary services: This is related to > to the first point. > - the definition of a unique service ID which is well known. > The tmodel approach is a proposal to generate and publish > such an ID. >=20 > I would certainly appreciate other solutions are avoiding at=20 > least one of the two levels of indirection. > Regards Bernhard >=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Mittwoch, 10. November 2004 07:54 > To: Henning Schulzrinne > Cc: Boehmer Bernhard ICM Berlin; Simple WG > Subject: Re: AW: AW: [Simple] Data model - attempt at summary >=20 >=20 > I agree with Henning here; I don't see how the layer of indirection=20 > solves anything. >=20 > -Jonathan R. >=20 > Henning Schulzrinne wrote: >=20 > > Boehmer Bernhard ICM Berlin wrote: > >=20 > >> Hi Henning, > >> service ID: certainly indirection has its drawbacks; > >> in this case the main question is whether the higher > >> flexibility of indirection outweighs the overhead > >> introduced with that. Actually, the whole XML schema > >> architecture is using it heavily (this becomes obvious > >> to me each time I edit XML schemas without being connected > >> to the Internet...:). > >=20 > >=20 > > While it is easy for a mobile provider to publish a UDDI=20 > directory entry=20 > > for its limited number of phones, say, it seems much harder for the=20 > > average user in a corporate network or using a provider.=20 > They will have=20 > > to rely on the provider or corporate network to host this=20 > information.=20 > > Unless you want to rely on web pages for configuration,=20 > every new source=20 > > of information means that there needs to be authentication,=20 > a means to=20 > > publish this information and to change it. > >=20 > > The only advantage of inclusion by reference is space=20 > saving. Otherwise,=20 > > whatever service description you include by reference can also be=20 > > included by value. > >=20 > > The space saving only matters if the mobile transmits the=20 > information.=20 > > This seems unlikely, even with inclusion. > >=20 > > Thus, I'm at a loss to see why adding another protocol=20 > machinery for=20 > > managing UDDI stores to every PUA or PA adds significant value that=20 > > outweighs the complexity incurred. > >=20 > > Henning > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 11 09:47:53 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 JAA16626; Thu, 11 Nov 2004 09:47:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGG2-0003ja-Uz; Thu, 11 Nov 2004 09:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGCH-0000tl-07; Thu, 11 Nov 2004 09: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 1CSGAK-0000ZG-Bi for simple@megatron.ietf.org; Thu, 11 Nov 2004 09:43: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 JAA16248 for ; Thu, 11 Nov 2004 09:43:10 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGBU-0003eD-HL for simple@ietf.org; Thu, 11 Nov 2004 09:44:25 -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 iABEguF14104; Thu, 11 Nov 2004 16:42:57 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 16:42:35 +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 iABEgZrt019668; Thu, 11 Nov 2004 16:42:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00a36Obn; Thu, 11 Nov 2004 16:42:34 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 iABEgPa22932; Thu, 11 Nov 2004 16:42:25 +0200 (EET) Received: from [10.162.14.168] ([10.162.14.168]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 16:41:57 +0200 Message-ID: <41937A34.6060002@nokia.com> Date: Thu, 11 Nov 2004 16:41:56 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ben@nostrum.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2004 14:41:57.0812 (UTC) FILETIME=[988A8F40:01C4C7FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Comments on IANA registration at MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hi: During the SIMPLE WG meeting we have a short discussion of the IANA registration section in MSRP. Here are more detailed comments. I am basing these comments on the IANA registration section of draft-ietf-mmusic-sdp-new-21.txt Section 8.2.8, which contains instructions for registration of SDP parameters. SDP defines the m= line with the following format: m= ... And a typical MSRP m= line in SDP looks like: m=message 9 msrp * So the actions that are needed to the MSRP draft are: - MSRP needs to register "message" as a - MSRP needs to register "msrp" as a - Editorial: the registration text in Section 15.3 should follow the template in sdp-new. This requires things like contact information, one paragraph explanation, etc. 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 Nov 11 10:32: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 KAA22825; Thu, 11 Nov 2004 10:32:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGx0-0004s7-Cs; Thu, 11 Nov 2004 10:33:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGrh-0007UO-HM; Thu, 11 Nov 2004 10:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGnB-00067s-Bz for simple@megatron.ietf.org; Thu, 11 Nov 2004 10:23:21 -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 KAA21930 for ; Thu, 11 Nov 2004 10:23:19 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGoM-0004gO-Th for simple@ietf.org; Thu, 11 Nov 2004 10:24:35 -0500 Received: from razor.cs.columbia.edu (IDENT:ptMiVq7GTOxuh9dBXuW/YvF0rJcLx8WB@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iABFNCRX007033; Thu, 11 Nov 2004 10:23:12 -0500 (EST) Received: from [127.0.0.1] (IDENT:asn5O4vhgTjCCaoWj/Taa+/cNjmE2Fzn@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iABFNBU3008012; Thu, 11 Nov 2004 10:23:12 -0500 Message-ID: <419383E6.5030802@cs.columbia.edu> Date: Thu, 11 Nov 2004 10:23:18 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: In-Reply-To: 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.11.10.8 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Markus Isomaki wrote: > What is needed is merely a way to be able to define authorization > rules, which can select this type of tuples individually. Currently > you can do this only if you support GRUU. I think this is the main > use case for having some other identifier available for the > selection. > > So maybe the "service ID" as such is not needed after all? We already have a tuple ID for unique identification. I don't see how another random-looking identifier adds significant value. The only value I can see is that you'd have multiple tuples that have an identical service and you'd want to filter all of them, without doing detailed XML element and attribute matching. I suspect this is not all that common. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 11 11:53: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 LAA00894; Thu, 11 Nov 2004 11:53:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIDF-0006rC-BP; Thu, 11 Nov 2004 11:54:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSI40-0006YB-Et; Thu, 11 Nov 2004 11:44:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHuZ-0004SQ-JH for simple@megatron.ietf.org; Thu, 11 Nov 2004 11:35: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 LAA28822 for ; Thu, 11 Nov 2004 11:35:01 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHvl-0006If-Gh for simple@ietf.org; Thu, 11 Nov 2004 11:36:18 -0500 Received: from [130.129.132.245] ([130.129.132.245]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iABGYmmn073978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2004 10:34:53 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <419394A9.303@nostrum.com> Date: Thu, 11 Nov 2004 10:34:49 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston , Henry Sinnreich , alan@telchemy.com, aspen@nortelnetworks.com X-Enigmail-Version: 0.86.1.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: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] PUBLISH in SIP Performance Report Event X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit I just want to make a quick comment on the use of PUBLISH in this document. I think there needs to be some clarification on when this is sent -- that is, how the UA knows that the proxy *wants* these publication messages. From the text currently in the draft, this looks an awful lot like using PUBLISH as an end-around sending unsolicited NOTIFY messages by simply changing the method name. I hope that I've misunderstood -- in which case some clarifying text might be in order; otherwise, I'm very concerned about the precedent this document sets. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 11 13:49:26 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 NAA11492; Thu, 11 Nov 2004 13:49:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSK1r-0001CM-74; Thu, 11 Nov 2004 13:50:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSJwA-0008Oa-IN; Thu, 11 Nov 2004 13:44:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSJr3-0007LD-FR for simple@megatron.ietf.org; Thu, 11 Nov 2004 13:39: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 NAA10981 for ; Thu, 11 Nov 2004 13:39: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 1CSJsG-00012X-Cx for simple@ietf.org; Thu, 11 Nov 2004 13:40:49 -0500 Received: from [130.129.132.245] ([130.129.132.245]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iABIdK9W085390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2004 12:39:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4193B1D8.8000302@nostrum.com> Date: Thu, 11 Nov 2004 12:39:20 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Simple] PUBLISH in SIP Performance Report Event References: <419394A9.303@nostrum.com> In-Reply-To: <419394A9.303@nostrum.com> X-Enigmail-Version: 0.86.1.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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Alan Johnston , aspen@nortelnetworks.com, simple@ietf.org, Henry Sinnreich , alan@telchemy.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Sorry -- wrong list (typo)... taking to SIPPING. /a Adam Roach wrote: > I just want to make a quick comment on the use of PUBLISH in this > document. I think there needs to be some clarification on when this is > sent -- that is, how the UA knows that the proxy *wants* these > publication messages. From the text currently in the draft, this looks > an awful lot like using PUBLISH as an end-around sending unsolicited > NOTIFY messages by simply changing the method name. I hope that I've > misunderstood -- in which case some clarifying text might be in order; > otherwise, I'm very concerned about the precedent this document sets. > > /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 Thu Nov 11 15:03:52 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 PAA18977; Thu, 11 Nov 2004 15:03:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLBr-00034U-8S; Thu, 11 Nov 2004 15:05:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSL0D-0005Dm-Ri; Thu, 11 Nov 2004 14:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKss-0003Yk-AZ for simple@megatron.ietf.org; Thu, 11 Nov 2004 14:45:30 -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 OAA16701 for ; Thu, 11 Nov 2004 14:45:29 -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 1CSKu5-0002XV-Ch for simple@ietf.org; Thu, 11 Nov 2004 14:46:46 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2004 11:59:04 -0800 X-BrightmailFiltered: true 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 iABJipoo018063; Thu, 11 Nov 2004 11:44:53 -0800 (PST) Received: from cisco.com (rtp-vpn1-132.cisco.com [10.82.224.132]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMZ04723; Thu, 11 Nov 2004 14:44:51 -0500 (EST) Message-ID: <4193C133.2010608@cisco.com> Date: Thu, 11 Nov 2004 14:44:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Simple] MSRP: 413 response needed? References: <4192362E.40904@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Adam, I can imagine some use for this, but is it worth cluttering up things with another error just for this case? It would then have to be accompanied by explicit support in the UA (and its UI) to determine when to send such a status. I'm on the fence. Paul Adam Roach wrote: > So, I'm looking at the case where I have a client that wants to say, "I > want to keep getting your messages on this session, and I don't want to > suppress your sending of any particular data type for this session, but > please stop sending this particular message." (More concretely: I don't > want to block all future attempts to send video/mpeg4, but please stop > sending me your copy of The Matrix.) > > I picked through all the MSRP status codes, and couldn't find one that > allows me to do this. > > It seems to me that addition of a 413 status code which means, "stop > this one message" would accomplish this task. > > Thoughts? > > /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 Thu Nov 11 17:33: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 RAA06991; Thu, 11 Nov 2004 17:33:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNWP-0007Vx-Tn; Thu, 11 Nov 2004 17:34:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNOD-0002UD-VX; Thu, 11 Nov 2004 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNDv-0007eM-E1 for simple@megatron.ietf.org; Thu, 11 Nov 2004 17:15:23 -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 RAA05058 for ; Thu, 11 Nov 2004 17:15:21 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNF9-0006wX-GH for simple@ietf.org; Thu, 11 Nov 2004 17:16:41 -0500 Received: from [130.129.132.245] ([130.129.132.245]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iABMFHSv004280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2004 16:15:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4193E475.5040206@nostrum.com> Date: Thu, 11 Nov 2004 16:15:17 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP: 413 response needed? References: <4192362E.40904@nostrum.com> <4193C133.2010608@cisco.com> In-Reply-To: <4193C133.2010608@cisco.com> X-Enigmail-Version: 0.86.1.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: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I can imagine some use for this, but is it worth cluttering up things > with another error just for this case? It would then have to be > accompanied by explicit support in the UA (and its UI) to determine > when to send such a status. I'm on the fence. You don't *have* to send it. However, I'm seeing a strong need for the *ability* to send it. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 11 19:56: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 TAA19842; Thu, 11 Nov 2004 19:56:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSPkp-0002C6-5K; Thu, 11 Nov 2004 19:57:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSPiO-0001m2-PT; Thu, 11 Nov 2004 19:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSPer-0001FY-QJ for simple@megatron.ietf.org; Thu, 11 Nov 2004 19:51:21 -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 TAA19543 for ; Thu, 11 Nov 2004 19:51:18 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSPg7-00026K-Io for simple@ietf.org; Thu, 11 Nov 2004 19:52:40 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id iAC0onbj005454 for ; Thu, 11 Nov 2004 18:50:49 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 11 Nov 2004 18:50:41 -0600 Message-ID: From: "Nancy Greene (QC/EMC)" To: simple@ietf.org Date: Thu, 11 Nov 2004 18:49:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Nancy Greene \(QC/EMC\)" Subject: [Simple] MSRP: need for 202 Accepted status code? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0544264120==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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. --===============0544264120== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C851.77463EC0" 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_01C4C851.77463EC0 Content-Type: text/plain; charset="iso-8859-1" When interworking with other messaging systems, it may be the case that the node doing the interworking doesn't actually know if the message has been successfully delivered. It just knows that the other system has taken over responsibility for delivering it. Perhaps then it would be good to allow a 202 Accepted status-code in REPORT. Nancy ------_=_NextPart_001_01C4C851.77463EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MSRP: need for 202 Accepted status code?

When interworking with other messaging systems, it = may be the case that the node doing the interworking doesn't actually = know if the message has been successfully delivered. It just knows that = the other system has taken over responsibility for delivering it. = Perhaps then it would be good to allow a 202 Accepted status-code in = REPORT.

Nancy


------_=_NextPart_001_01C4C851.77463EC0-- --===============0544264120== 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 --===============0544264120==-- From simple-bounces@ietf.org Thu Nov 11 20:21: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 UAA22343; Thu, 11 Nov 2004 20:21:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSQ9S-0002lY-8c; Thu, 11 Nov 2004 20:22:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSPvS-0003zM-Nk; Thu, 11 Nov 2004 20:08:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSPsE-0003Pg-Fe for simple@megatron.ietf.org; Thu, 11 Nov 2004 20: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 UAA20505 for ; Thu, 11 Nov 2004 20:05:09 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSPtU-0002N2-9b for simple@ietf.org; Thu, 11 Nov 2004 20:06:29 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2004 17:04:53 -0800 X-BrightmailFiltered: true 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 iAC14Sn0026248; Thu, 11 Nov 2004 17:04:29 -0800 (PST) Received: from cisco.com (rtp-vpn1-555.cisco.com [10.82.226.43]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMZ30935; Thu, 11 Nov 2004 20:04:33 -0500 (EST) Message-ID: <41940C21.3080103@cisco.com> Date: Thu, 11 Nov 2004 20:04:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: bernhard.boehmer@siemens.com, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Markus - comments at the end. Paul Markus.Isomaki@nokia.com wrote: > Hi Paul, > > See inline. > > Paul Kyzivat wrote: > >>Markus, >> >>To describe a service that can't be described with prescaps, you just >>need to use some other (perhaps proprietary) extension >>entitites within >>tuple or status. >> > > > Yes, I understand this is the idea. > > >>I had wanted the callerprefs extension mechanism mapped over >>to prescaps >>in order to make extensions to presence as simple as extensions to >>callee caps, but that got lost along the way. Nevertheless I >>don't think >>it is very hard to define your own xml schema for this purpose. >> > > > It is not hard as such. The problem I would like to address actually this: > The user has service foo that uses SIP to open some media sessions. > It is possible to create capability extensions which make it clear > for the other end that this is foo. However, is it possible for the > user to authorize the service tuple published by foo in some clear way? > Originally I thought class could be used as this type of selector > (although no conflict resolution exist for class values), but it is no > longer supported. Currently the only ways to select tuples in > authorization phase are URI scheme and URI itself. But if we accept the > case that there can be several tuples/services with the same URI, they > become an unseparable unit from authorization point of view. Some sort > of id in the tuples that services/publishers could consistently use > would help, and why not using that then to tell something to the > watchers too. I'm not sure why you would want to do this. Perhaps it is a capability that only some of your watchers possess, but does it hurt to tell the other watchers? If it is important to do so, then it ought to be equally important to be able to authorize based on other capabilities. For instance, maybe I don't want everyone to know that I have a phone with video capabilities. Currently this is handled by simply not disclosing the capability of concern. This works fine if I have a device with audio+video and I don't tell everyone about the video. It works less well if I hide both audio and video from some people, because then I am telling them I have an open device with no indication of supported media. Just one more reason why capabilities should be reported with both positive and negative values, so that the absence of a value isn't treated as having it. If it is really necessary to condition authorization on the presence or value of some arbitrary element in the tuple then presumably something could be added to the authorization rules to do this. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 11 20:33: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 UAA23465; Thu, 11 Nov 2004 20:33:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSQL9-00030Y-1W; Thu, 11 Nov 2004 20:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSQAA-0006b4-Hc; Thu, 11 Nov 2004 20:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSQ3k-0005X2-N9 for simple@megatron.ietf.org; Thu, 11 Nov 2004 20:17: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 UAA21918 for ; Thu, 11 Nov 2004 20:17:03 -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 1CSQ51-0002fB-8d for simple@ietf.org; Thu, 11 Nov 2004 20:18:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2004 17:30:42 -0800 X-BrightmailFiltered: true 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 iAC1GTKU002128; Thu, 11 Nov 2004 17:16:30 -0800 (PST) Received: from cisco.com (rtp-vpn1-555.cisco.com [10.82.226.43]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMZ31559; Thu, 11 Nov 2004 20:16:28 -0500 (EST) Message-ID: <41940EEB.6080607@cisco.com> Date: Thu, 11 Nov 2004 20:16:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Cc: hgs@cs.columbia.edu, simple@ietf.org, bernhard.boehmer@siemens.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > I have thought about this a bit and my current thinking is this: > - Prescaps and other decomposed capabilities are good as long as your application can interoperate with another application which only supports a subset of your capabilities. In some cases this is clearly useful, e.g. with different medias. > - If you have a proprietary application, which can ONLY work with another similar app, there is no use in decomposing the capabilities. So for each this kind of app you just define a single proprietary capability who is only understood by other similar apps. > - This type of proprietary app should be published in a separate tuple of its own, and actually SHOULD NOT included other capabilities. E.g. even if the app supported voice, there is no point listing that, if it can't work with another app that ONLY supports voice but not the proprietary part. Based on your assumptions I agree. (It would be better not to build the device this way, if possible.) It might be better to explicitly indicate that the "common" capabilities are *not* supported, just in case your special capability is filtered out or ignored and a watcher might assume you have some unstated capability. (e.g. voice.) > - On the other hand if you have an application which has a certain proprietary capability, but that is not essential, you can just include that in the tuple _in addition_ to all other capabilities that you might have. Yup. Much more friendly behavior. > (So using the example of the proprietary push-to-talk app that I described some time ago: I think that should just define a single capability extension, and definitely NOT include voice and half-duplex capabilities in its tuple to fool a watcher who has half-duplex VoIP to call.) In that case I agree. I think there is work to do to define half duplex more precisely. Maybe it will then be suitable to describe some kinds of PTT service, or maybe not. But I do think it would be better if PTT were defined in such a way that it would interoperate with a regular voice caller, perhaps in only a limited way. For instance the caller might not know about the floor control needed, and so it would have to be handled by the PTT UA, or by the "mixer" if one is in the call. This would obviously be limited for the unaware party, but maybe not so limited as not calling at all. > What is needed is merely a way to be able to define authorization rules, which can select this type of tuples individually. Currently you can do this only if you support GRUU. I think this is the main use case for having some other identifier available for the selection. I still don't quite get it re the authorization rules. See my prior reply. Paul > So maybe the "service ID" as such is not needed after all? > > Markus > > >>-----Original Message----- >>From: ext Boehmer Bernhard Com Berlin >>[mailto:bernhard.boehmer@siemens.com] >>Sent: 11 November, 2004 11:29 >>To: 'Jonathan Rosenberg'; Henning Schulzrinne >>Cc: Boehmer Bernhard Com Berlin; Simple WG; Isomaki Markus >>(Nokia-TP/Espoo) >>Subject: RE: AW: AW: [Simple] Data model - attempt at summary >> >> >>Anything is a hard word ... >>There are different issues which must be addressed: >> >>- the description of services; I'm still not convinced >>that the description via prefs is applicable to services >>in general. Pointing to a description document is a way >>to address that. A more direct poiting to such a doc would >>be definitly nicer if possible. >>- the inclusion of proprietary services: This is related to >> to the first point. >>- the definition of a unique service ID which is well known. >>The tmodel approach is a proposal to generate and publish >>such an ID. >> >>I would certainly appreciate other solutions are avoiding at >>least one of the two levels of indirection. >> Regards Bernhard >> >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Mittwoch, 10. November 2004 07:54 >>To: Henning Schulzrinne >>Cc: Boehmer Bernhard ICM Berlin; Simple WG >>Subject: Re: AW: AW: [Simple] Data model - attempt at summary >> >> >>I agree with Henning here; I don't see how the layer of indirection >>solves anything. >> >>-Jonathan R. >> >>Henning Schulzrinne wrote: >> >> >>>Boehmer Bernhard ICM Berlin wrote: >>> >>> >>>>Hi Henning, >>>>service ID: certainly indirection has its drawbacks; >>>>in this case the main question is whether the higher >>>>flexibility of indirection outweighs the overhead >>>>introduced with that. Actually, the whole XML schema >>>>architecture is using it heavily (this becomes obvious >>>>to me each time I edit XML schemas without being connected >>>>to the Internet...:). >>> >>> >>>While it is easy for a mobile provider to publish a UDDI >> >>directory entry >> >>>for its limited number of phones, say, it seems much harder for the >>>average user in a corporate network or using a provider. >> >>They will have >> >>>to rely on the provider or corporate network to host this >> >>information. >> >>>Unless you want to rely on web pages for configuration, >> >>every new source >> >>>of information means that there needs to be authentication, >> >>a means to >> >>>publish this information and to change it. >>> >>>The only advantage of inclusion by reference is space >> >>saving. Otherwise, >> >>>whatever service description you include by reference can also be >>>included by value. >>> >>>The space saving only matters if the mobile transmits the >> >>information. >> >>>This seems unlikely, even with inclusion. >>> >>>Thus, I'm at a loss to see why adding another protocol >> >>machinery for >> >>>managing UDDI stores to every PUA or PA adds significant value that >>>outweighs the complexity incurred. >>> >>>Henning >>> >>>_______________________________________________ >>>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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 12 22:39: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 WAA25725; Fri, 12 Nov 2004 22:39:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSomK-0000Wn-AM; Fri, 12 Nov 2004 22:40:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSoip-0005ET-G3; Fri, 12 Nov 2004 22:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSogN-0004uI-DT for simple@megatron.ietf.org; Fri, 12 Nov 2004 22:34: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 WAA25632 for ; Fri, 12 Nov 2004 22:34:32 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSohs-0000OO-H9 for simple@ietf.org; Fri, 12 Nov 2004 22:36:08 -0500 Received: from razor.cs.columbia.edu (IDENT:UYqkZXCl1tjbSL5yAqRl85PLmg1Exusi@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAD3YSRX026670; Fri, 12 Nov 2004 22:34:28 -0500 (EST) Received: from [127.0.0.1] (IDENT:aO8o23tyI8W30FzuA4creaOiwv/dvp2J@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAD3YRU3018969; Fri, 12 Nov 2004 22:34:27 -0500 Message-ID: <419580C2.8000201@cs.columbia.edu> Date: Fri, 12 Nov 2004 22:34:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] Presence auth rules: authenticated condition and exceptions References: In-Reply-To: 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.11.12.3 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: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Due to the basic premise of additive permissions, it is unlikely that blacklisting is going to work as users expect. Rules can only add permissions, they cannot take them away. This means that if there is any more generic rule that, for example, allows authenticated (but unknown) users to request permission to subscribe, the blacklist would also have to be included in that rule. This seems rather brittle and likely to cause surprises, but is possible. To address the other issue raised in the SIMPLE WG session discussion earlier this week: One possible proposal, instead of an authenticated flag, is to allow a wildcard character in the element, as in * which matches any *authenticated* identity (whether the rules have access to the name or not). This would allow to express the desired behavior of querying for subscription permission. Non-authenticated names would not match such -tagged rules, but could be matched by leaving out the match altogether, as before. I believe this also allows us to get rid of the not-very-well-defined case of anonymous. We could add a 'do not match these' clause to rules, i.e., a condition on identity that causes the rule *not* to match. A fictitious example that extends the existing domain-level match ( + ): * badguy@example.com bozo@example.org The disadvantage is that this does add more failure cases, albeit harmless ones, such as goodguy@example.com badguy@example.com Here, the is meaningless since it would never match to begin with. As I mentioned above, this only allows true blacklisting if the is included in all "*" rules. Henning Markus.Isomaki@nokia.com wrote: > Hi, > > I know this has been discussed several times, but I'd still like to > propose it once again. > > I believe the conclusion of yesterday's SIMPLE meeting was that there > will be a new condition for pres auth rules called authenticated, > which would be fulfilled by any request that came from an > authenticated source. I would like to include the exception clause > for that, which would allow "blacklisting" _within_ the scope of > authenticated identities. Currently this is only allowed within a > single domain. While such blacklisting would be pretty useless in > systems where it is easy to generate new authenticated identities, it > would be valuable in more restricted systems where there is certain > cost/policy for obtaining identities. I understand that once more and > more domains are interconnected to the system, the easiness of > getting a new identity is based on the "weakest link", and thus it is > hard to maintain the restrictiveness for large multi-domain systems. > Nevertheless, there is strong user expectation for this type of > feature. > > Thanks, Markus > > _______________________________________________ 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 Nov 15 16:37: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 QAA13042; Mon, 15 Nov 2004 16:37:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CToZw-0002hq-Iu; Mon, 15 Nov 2004 16:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CToMA-0005Aa-5B; Mon, 15 Nov 2004 16:25:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTo3n-0001VI-EA for simple@megatron.ietf.org; Mon, 15 Nov 2004 16:06: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 QAA05822 for ; Mon, 15 Nov 2004 16:06:49 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTo5o-0000cV-N7 for simple@ietf.org; Mon, 15 Nov 2004 16:08:59 -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 iAFL5Uv23282; Mon, 15 Nov 2004 23:05:30 +0200 (EET) X-Scanned: Mon, 15 Nov 2004 23:05:10 +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 iAFL5Agn012593; Mon, 15 Nov 2004 23:05:10 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00lRWze7; Mon, 15 Nov 2004 23:05:08 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 iAFL57S01242; Mon, 15 Nov 2004 23:05:07 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Nov 2004 23:05:05 +0200 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Nov 2004 23:05:04 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Simple] Data model - attempt at summary Date: Mon, 15 Nov 2004 23:05:04 +0200 Message-ID: Thread-Topic: AW: AW: [Simple] Data model - attempt at summary Thread-Index: AcTIU7DoO8nh4YjRQS+lZIZh9hKEcAC/0p6Q To: X-OriginalArrivalTime: 15 Nov 2004 21:05:04.0285 (UTC) FILETIME=[C732FCD0:01C4CB56] X-Spam-Score: 0.3 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: bernhard.boehmer@siemens.com, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Hi, Perhaps I've made things sound too complicated, so I try to clarify. The scenario which I'm thinking is such that the devices have open SIP = and presence APIs, on top of which third party developers are able to = create their own applications. For instance currently there is a SIP = stack for Symbian OS, and you can install variety of SIP-based apps, = such as push-to-talk, file sharing, battleship game, voice IM etc. on = top of it. Obviously there will in addition be the "main" SIP UA that = takes care of the core things such as voice, video, MSRP and = conferencing.=20 Each of these applications is pretty independent of each other and can't = share capabilities with other apps. So what they need to do is to = publish their own individual tuples, which describe the capabilities of = that application only. Merging the tuples would give the watchers a = wrong idea ("battleship game with PTT suppport" etc.). The applications = can very well share the same SIP AoR, since they sit on top of a common = SIP stack, which can determine (in most cases) the right application for = the initial request based on e.g. caller preferences, other header = values, medias in SDP or whatever. The basic requirement is that these applications should be able to = control the authorization to the tuples _they_ publish. For instance PTT = app will have a white list to set who are able to see the PTT related = tuple(s). It is possible to have a common UI for this to cover all apps, = but app specific UIs will also contain authorization. The requirements derived from this real life scenario are: 1. Applications must be able to publish tuples using the SIP AoR as = their contact address in such way that the presence server won't merge = the tuples. -> Composition rules should allow multiple tuples per AoR, and not = override or merge them unless there is some explicit indication on this. 2. Applications must be able to include enough information in their = tuples so that other similar applications can identify them. -> Prescaps + proprietary capability elements is enough. Service ID is = not necessary. 3. Applications should be able to create authorization rules that govern = access to the tuples published by them -> Some kind of static identifier for the tuples used between PUA and = PS would do. If nothing else is provided, at least tuple ids should be = then usable for authorization rules in addition to contact URIs. We can = use fixed tuple ids that persist over time, although that is not exactly = how those ids were meant to be used. Another possibilty would be the = class element, for which I currently don't see any other use. I hope Jonathan could include this type of identifier (tuple id, class, = whatever) based tuple selection approach in the authorization rules = document. Otherwise it is difficult to support requirement 3. I don't think doing authorization based on capabilities is essential, = although it might be useful in some specific cases. Regards, Markus=20 =20 > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 12 November, 2004 03:05 > To: Isomaki Markus (Nokia-TP/Espoo) > Cc: jdrosen@cisco.com; hgs@cs.columbia.edu; simple@ietf.org; > bernhard.boehmer@siemens.com > Subject: Re: AW: AW: [Simple] Data model - attempt at summary >=20 >=20 > Markus - comments at the end. >=20 > Paul >=20 > Markus.Isomaki@nokia.com wrote: > > Hi Paul, > >=20 > > See inline. > >=20 > > Paul Kyzivat wrote: > >=20 > >>Markus, > >> > >>To describe a service that can't be described with=20 > prescaps, you just=20 > >>need to use some other (perhaps proprietary) extension=20 > >>entitites within=20 > >>tuple or status. > >> > >=20 > >=20 > > Yes, I understand this is the idea. > > =20 > >=20 > >>I had wanted the callerprefs extension mechanism mapped over=20 > >>to prescaps=20 > >>in order to make extensions to presence as simple as extensions to=20 > >>callee caps, but that got lost along the way. Nevertheless I=20 > >>don't think=20 > >>it is very hard to define your own xml schema for this purpose. > >> > >=20 > >=20 > > It is not hard as such. The problem I would like to address=20 > actually this:=20 > > The user has service foo that uses SIP to open some media sessions. > > It is possible to create capability extensions which make it clear > > for the other end that this is foo. However, is it possible for the > > user to authorize the service tuple published by foo in=20 > some clear way? > > Originally I thought class could be used as this type of selector > > (although no conflict resolution exist for class values),=20 > but it is no > > longer supported. Currently the only ways to select tuples in > > authorization phase are URI scheme and URI itself. But if=20 > we accept the > > case that there can be several tuples/services with the=20 > same URI, they > > become an unseparable unit from authorization point of=20 > view. Some sort > > of id in the tuples that services/publishers could consistently use > > would help, and why not using that then to tell something to the > > watchers too. >=20 > I'm not sure why you would want to do this. Perhaps it is a=20 > capability=20 > that only some of your watchers possess, but does it hurt to tell the=20 > other watchers? >=20 > If it is important to do so, then it ought to be equally=20 > important to be=20 > able to authorize based on other capabilities. For instance, maybe I=20 > don't want everyone to know that I have a phone with video=20 > capabilities.=20 > Currently this is handled by simply not disclosing the capability of=20 > concern. This works fine if I have a device with audio+video=20 > and I don't=20 > tell everyone about the video. It works less well if I hide=20 > both audio=20 > and video from some people, because then I am telling them I have an=20 > open device with no indication of supported media. Just one=20 > more reason=20 > why capabilities should be reported with both positive and negative=20 > values, so that the absence of a value isn't treated as having it. >=20 > If it is really necessary to condition authorization on the=20 > presence or=20 > value of some arbitrary element in the tuple then presumably=20 > something=20 > could be added to the authorization rules to do this. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 15 17:14: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 RAA18497; Mon, 15 Nov 2004 17:14:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTp9p-000443-1r; Mon, 15 Nov 2004 17:17:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTp5O-0002km-Gx; Mon, 15 Nov 2004 17:12:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTp0B-0000Tw-Fs for simple@megatron.ietf.org; Mon, 15 Nov 2004 17:07: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 RAA17800 for ; Mon, 15 Nov 2004 17:07:09 -0500 (EST) Received: from av3-1-sn4.m-sp.skanova.net ([81.228.10.114]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTp2C-0003r6-Vf for simple@ietf.org; Mon, 15 Nov 2004 17:09:20 -0500 Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 577C837EBF; Mon, 15 Nov 2004 23:06:30 +0100 (CET) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 4910737E6A; Mon, 15 Nov 2004 23:06:30 +0100 (CET) Received: from vit (h79n2fls31o265.telia.com [217.208.189.79]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 27F7B37E46; Mon, 15 Nov 2004 23:06:30 +0100 (CET) From: "Gunnar Hellstrom" To: "SIMPLE" Date: Mon, 15 Nov 2004 23:06:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: Toip list Subject: [Simple] Pseudo real time text transmission with SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable You remember the intensive discussion we had this summer about using SIMP= LE protocols for real time text transmission. Occasionally that idea pops up again. The benefit is said to be higher pr= obability for mainstream implementation if the same protocol is reused for both messagi= ng and real time. We decided before, that real time text transmission of the type we do wit= h RTP in RFC2793, with transmission at every 300 ms, is out of scope for SIMPLE. But what if we define a pseudo real time mode, e.g. transmitting at some = seconds interval ( when there is something to transmit), and also when the user has typed = a sentence delimiter. What are the feelings about suitable minimum transmission intervals in a = session from a network point of view: 1. If SIP MESSAGE is used for the transmission? 2. If MSRP directly between UA:s is used for the transmission? ( For the moment not considering what the real time user feels about this= kind of communication, that may be next question.) Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 15 18:49: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 SAA27102; Mon, 15 Nov 2004 18:49:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTqd3-0005vK-7x; Mon, 15 Nov 2004 18:51:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqYN-0003in-Nn; Mon, 15 Nov 2004 18:46:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqWQ-0003F3-C1 for simple@megatron.ietf.org; Mon, 15 Nov 2004 18:44:36 -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 SAA26697 for ; Mon, 15 Nov 2004 18:44:31 -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 1CTqYL-0005mz-MN for simple@ietf.org; Mon, 15 Nov 2004 18:46:44 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Nov 2004 15:28:13 -0800 X-BrightmailFiltered: true 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 iAFNDDOx002433; Mon, 15 Nov 2004 15:13:18 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB14788; Mon, 15 Nov 2004 18:13:12 -0500 (EST) Message-ID: <41993807.20408@cisco.com> Date: Mon, 15 Nov 2004 18:13:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: bernhard.boehmer@siemens.com, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > Perhaps I've made things sound too complicated, so I try to clarify. The clarification does help. > The scenario which I'm thinking is such that the devices have open SIP and presence APIs, on top of which third party developers are able to create their own applications. For instance currently there is a SIP stack for Symbian OS, and you can install variety of SIP-based apps, such as push-to-talk, file sharing, battleship game, voice IM etc. on top of it. Obviously there will in addition be the "main" SIP UA that takes care of the core things such as voice, video, MSRP and conferencing. Do these applications have different *contact* addresses? E.g. - sip:ptt@alice-phone.atlanta.com - sip:battleship@alice-phone.atlanta.com - sip:im@alice-phone.atlanta.com Or are these demultiplexed in some more obscure way that is not clearly identifiable remotely? > Each of these applications is pretty independent of each other and can't share capabilities with other apps. OK. At least this is very clearly an OR-OF-ANDS presence representation need, as opposed to the just conflicting views where one is right be we don't know which one. In some cases I suppose the independence is intrinsic - you just can't share that little screen effectively between the battleship game and the IM application. In other cases it may just be an artifact of the implementation model that they aren't integrated. > So what they need to do is to publish their own individual tuples, which describe the capabilities of that application only. Merging the tuples would give the watchers a wrong idea ("battleship game with PTT suppport" etc.). I know that Henning is of the opinion that there is no need to understand the difference between conflicting tuples and the OR-OF-ANDS case, because they aren't operationally different to the end user. But they are semantically different. And while that difference may be irrelevant to the ultimate watcher, it does make a difference to a composer, including a UA that does its own composition for purposes of display. You have that if you can use a different contact address for each application. Using GRUUs would solve this. But I guess you have a strong resistance to using GRUUs. The AOR, with a uri parameter to distinguish the contacts, would also work. However, with the exception of the grid parameter on gruus, you can't count on uri parameters of an AOR being passed on when a request is routed through the AOR to a registered contact. But if you are content to use the AOR, because you discriminate on some other basis, then maybe it doesn't matter to you that the parameter gets lost - it will still serve to keep the tuples distinct. So maybe you could populate your tuples with contacts like: or > The applications can very well share the same SIP AoR, since they sit on top of a common SIP stack, which can determine (in most cases) the right application for the initial request based on e.g. caller preferences, other header values, medias in SDP or whatever. > > The basic requirement is that these applications should be able to control the authorization to the tuples _they_ publish. For instance PTT app will have a white list to set who are able to see the PTT related tuple(s). It is possible to have a common UI for this to cover all apps, but app specific UIs will also contain authorization. The idea that applications will control authorization of specific tuples that share the same AOR is troubling to me - moreso if they advertise the same contact information. But it is probably not my place to argue about what kind of UI you want to provide. As long as there is *something* that marks the tuples as being different, it should be possible to construct an authorization rule that is conditioned on that discriminating attribute. However, there may be considerable difficulty in managing the collected set of rules after the fact. How do you select the set of rules that belong to one application so that it may edit them and not those of another application? > The requirements derived from this real life scenario are: > 1. Applications must be able to publish tuples using the SIP AoR as their contact address in such way that the presence server won't merge the tuples. > -> Composition rules should allow multiple tuples per AoR, and not override or merge them unless there is some explicit indication on this. > 2. Applications must be able to include enough information in their tuples so that other similar applications can identify them. > -> Prescaps + proprietary capability elements is enough. Service ID is not necessary. > 3. Applications should be able to create authorization rules that govern access to the tuples published by them > -> Some kind of static identifier for the tuples used between PUA and PS would do. If nothing else is provided, at least tuple ids should be then usable for authorization rules in addition to contact URIs. We can use fixed tuple ids that persist over time, although that is not exactly how those ids were meant to be used. Another possibilty would be the class element, for which I currently don't see any other use. > > I hope Jonathan could include this type of identifier (tuple id, class, whatever) based tuple selection approach in the authorization rules document. Otherwise it is difficult to support requirement 3. > > I don't think doing authorization based on capabilities is essential, although it might be useful in some specific cases. I am interested to hear your response to my comments above. I feel we are getting closer to a common understanding, although slowly. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 16 00:03: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 AAA03293; Tue, 16 Nov 2004 00:03:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTvXi-0003Rd-QG; Tue, 16 Nov 2004 00:06:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTvUO-0001iD-M0; Tue, 16 Nov 2004 00:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTvSI-0001DA-Hl for simple@megatron.ietf.org; Tue, 16 Nov 2004 00:00: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 AAA03114 for ; Tue, 16 Nov 2004 00:00:35 -0500 (EST) Received: from av1-2-sn4.m-sp.skanova.net ([81.228.10.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTvUF-0003NU-TG for simple@ietf.org; Tue, 16 Nov 2004 00:02:51 -0500 Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 6F71337E47; Tue, 16 Nov 2004 05:59:48 +0100 (CET) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6093237E43; Tue, 16 Nov 2004 05:59:48 +0100 (CET) Received: from vit (h79n2fls31o265.telia.com [217.208.189.79]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 3B39637E45; Tue, 16 Nov 2004 05:59:48 +0100 (CET) From: "Gunnar Hellstrom" To: "'SIMPLE'" Date: Tue, 16 Nov 2004 05:59:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Cc: "'Toip list'" Subject: [Simple] RE: Pseudo real time text transmission with SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Yes, without considering usability aspects, and without considering inter= operability aspects, I just want to get some grip of how often the SIMPLE experts thi= nk it is reasonable for a UA to: 1. Send a SIP MESSAGE 2. Send an MSRP SEND 0.3 seconds, 0.5 seconds, 1 second, 2 seconds, 5 seconds, 10 seconds? The payload would be 1 - 100 UTF-8 characters depending on the buffer tim= e and the intensity of the sender. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On >Behalf Of Gregg Vanderheiden >Sent: Monday, November 15, 2004 11:35 PM >To: 'Gunnar Hellstrom'; 'SIMPLE' >Cc: 'Toip list' >Subject: RE: Pseudo real time text transmission with SIMPLE > > >A fundamental question may be interoperability. > >If this is just 'effective text conversation while in another interactiv= e >medium that involves voice conversation" then this would not come up. > >If this was "what will this group use for telephone equivalence" then it >does. > >I can see however, how these two questions could be addressed separately= . > > >Gregg > > -- ------------------------------ >Gregg C Vanderheiden Ph.D. >Professor - Ind. Engr. & BioMed Engr. >Director - Trace R & D Center >University of Wisconsin-Madison > > >-----Original Message----- >From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Beha= lf >Of Gunnar Hellstrom >Sent: Monday, November 15, 2004 4:07 PM >To: SIMPLE >Cc: Toip list >Subject: Pseudo real time text transmission with SIMPLE > >You remember the intensive discussion we had this summer about using SIM= PLE >protocols for >real time text transmission. > >Occasionally that idea pops up again. The benefit is said to be higher >probability for >mainstream implementation if the same protocol is reused for both messag= ing >and real time. > >We decided before, that real time text transmission of the type we do wi= th >RTP in RFC2793, >with transmission at every 300 ms, is out of scope for SIMPLE. > >But what if we define a pseudo real time mode, e.g. transmitting at some >seconds interval >( when there is something to transmit), and also when the user has typed= a >sentence >delimiter. > >What are the feelings about suitable minimum transmission intervals in a >session from a >network point of view: > >1. If SIP MESSAGE is used for the transmission? > >2. If MSRP directly between UA:s is used for the transmission? > >( For the moment not considering what the real time user feels about thi= s >kind of >communication, that may be next question.) > >Regards > >Gunnar > >------------------------------------------- >Gunnar Hellstr=F6m >Omnitor AB >Renathv=E4gen 2 >SE 121 37 Johanneshov >SWEDEN >+46 8 556 002 03 >Mob: +46 708 204 288 >www.omnitor.se >Gunnar.Hellstrom@Omnitor.se >-------------------------------------------- > > > >- >This list is maintained by Snowshore Networks - http://www.snowshore.com >All comments on this list are the comments of the message originators an= d >Snowshore is not to be held responsible for any actions or comments foun= d >on this list. The archives for this list can be found at >http://flyingfox.snowshore.com/toip_archive/maillist.html > > >- >This list is maintained by Snowshore Networks - http://www.snowshore.com >All comments on this list are the comments of the message originators an= d >Snowshore is not to be held responsible for any actions or comments foun= d >on this list. The archives for this list can be found at >http://flyingfox.snowshore.com/toip_archive/maillist.html > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 16 03:08: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 DAA02007; Tue, 16 Nov 2004 03:08:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTyQ5-0006y3-Nt; Tue, 16 Nov 2004 03:10:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyMt-0008AU-CB; Tue, 16 Nov 2004 03:07:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyKu-0007se-6F for simple@megatron.ietf.org; Tue, 16 Nov 2004 03:05: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 DAA01511 for ; Tue, 16 Nov 2004 03:05:09 -0500 (EST) Received: from mail.rnid.org.uk ([217.158.120.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTyMs-0006s7-1m for simple@ietf.org; Tue, 16 Nov 2004 03:07:24 -0500 Received: from JUPITER-MSG.rnid.org.uk (unverified [192.168.122.1]) by mail.rnid.org.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Tue, 16 Nov 2004 08:07:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Nov 2004 08:07:15 -0000 Message-ID: <4818CE251FC66942A7EF35B92695246E024EC414@JUPITER-MSG.ad.rnid.org> Thread-Topic: Pseudo real time text transmission with SIMPLE Thread-Index: AcTLX+n0OF+vseSLRzmJX4Jgd0C37gAUuDow From: "Guido Gybels" To: "Gunnar Hellstrom" , "SIMPLE" X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: Toip list Subject: [Simple] RE: Pseudo real time text transmission with SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Gunnar, <<( For the moment not considering what the real time user feels about this= kind of communication, that may be next question.)>> Why? It seems to me that technology should be driven by user needs, not the= other way around. Guido Guido Gybels Director of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK Tel +44(0)207 294 3713 Fax +44(0)207 296 8069 ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ******************************************************************** _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 16 05:06: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 FAA10718; Tue, 16 Nov 2004 05:06:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU0Gp-0000xi-Th; Tue, 16 Nov 2004 05:09:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU07B-0004n2-Kp; Tue, 16 Nov 2004 04:59:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU04L-0004Iz-R5 for simple@megatron.ietf.org; Tue, 16 Nov 2004 04:56:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09905 for ; Tue, 16 Nov 2004 04:56:12 -0500 (EST) Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU06V-0000k3-Oi for simple@ietf.org; Tue, 16 Nov 2004 04:58:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Nov 2004 11:55:41 +0200 Message-ID: Thread-Topic: rfc3903 - PUBLISH modify Thread-Index: AcTLwm6eI5yV+nwzTeCMo1g2f3wdDw== From: "Adi Even-Tzur" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Subject: [Simple] rfc3903 - PUBLISH modify X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0262922626==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb This is a multi-part message in MIME format. --===============0262922626== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CBC2.6EA0289A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CBC2.6EA0289A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 RFC 3903 states: =20 "If the entity-tag matches previously published event state at the ESC, that event state is replaced by the=20 event state carried in the PUBLISH request, and the EPA receives a 2xx response." (section 4.4, regarding Modifying Event State). =20 My question: what the meaning of replace is - If the Modify PUBLISH contains only subset of the tuples of the Initial PUBLISH, whether the tuples that are missing in the Modify PUBLISH=20 should be removed from the event state by the ESC or should they stay without change? =20 Thanks, Adi. =20 =20 ------_=_NextPart_001_01C4CBC2.6EA0289A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC 3903 =
states:
 
"If the entity-tag =
matches previously published event state at the ESC, that event state is =
replaced by the =

 event state carried in the PUBLISH request, and the =
EPA receives a 2xx =
response."
(section 4.4, regarding =
Modifying =
Event =
State).<=
/pre>
 
My question: what the =
meaning of replace is -
If the Modify PUBLISH =
contains only subset of the tuples of the Initial PUBLISH, whether the tuples that are missing in the Modify PUBLISH =

should be removed from the event =
state by the ESC or should they stay without =
change?
 
Thanks,
Adi.
 



 
=00 ------_=_NextPart_001_01C4CBC2.6EA0289A-- --===============0262922626== 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 --===============0262922626==-- From simple-bounces@ietf.org Tue Nov 16 07:52: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 HAA24978; Tue, 16 Nov 2004 07:52:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU2qu-0004ZN-8o; Tue, 16 Nov 2004 07:54:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU2nT-00076J-QF; Tue, 16 Nov 2004 07:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU2jE-0006H1-PX for simple@megatron.ietf.org; Tue, 16 Nov 2004 07:46:36 -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 HAA24513 for ; Tue, 16 Nov 2004 07:46:36 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU2lQ-0004Pb-FB for simple@ietf.org; Tue, 16 Nov 2004 07:48:53 -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 iAGCkWP20749; Tue, 16 Nov 2004 14:46:33 +0200 (EET) X-Scanned: Tue, 16 Nov 2004 14:44:34 +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 iAGCiYNe010758; Tue, 16 Nov 2004 14:44:34 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00WFM0br; Tue, 16 Nov 2004 14:44:32 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 iAGCiPa18689; Tue, 16 Nov 2004 14:44:25 +0200 (EET) Received: from [172.21.34.165] ([172.21.34.165]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 14:44:11 +0200 Message-ID: <4199F61A.8020003@nokia.com> Date: Tue, 16 Nov 2004 14:44:10 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Adi Even-Tzur Subject: Re: [Simple] rfc3903 - PUBLISH modify References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2004 12:44:11.0879 (UTC) FILETIME=[F8FB7F70:01C4CBD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Hi Adi, Admittedly, the phrase "replace" is misleading. This of course depends on the PUBLISH content. In presence, a PUBLISH containing full PIDF would indeed replace the initial publication. However, with e.g. partial publication, the modifying publication would actually patch the initial publication, not replace it. Cheers, Aki ext Adi Even-Tzur wrote: > Hi, > > > > RFC 3903 states: > > > > "If the entity-tag matches previously published event state at the > ESC, that event state is *replaced* by the > > event state carried in the PUBLISH request, and the EPA receives a > 2xx response." > > (section 4.4, regarding Modifying Event State). > > > > My question: what the meaning of replace is - > > If the Modify PUBLISH contains only subset of the tuples of the > Initial PUBLISH, whether the tuples that are missing in the Modify > PUBLISH > > should be removed from the event state by the ESC or should they stay > without change? > > > > Thanks, > > Adi. > > > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ 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 Nov 16 08:52: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 IAA29011; Tue, 16 Nov 2004 08:52:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3mu-0005q4-H2; Tue, 16 Nov 2004 08:54:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3io-00066L-8R; Tue, 16 Nov 2004 08:50:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3fc-0005g5-Ip for simple@megatron.ietf.org; Tue, 16 Nov 2004 08:46: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 IAA28715 for ; Tue, 16 Nov 2004 08:46:55 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3ho-0005lD-PC for simple@ietf.org; Tue, 16 Nov 2004 08:49:14 -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 iAGDjiv23216; Tue, 16 Nov 2004 15:45:44 +0200 (EET) X-Scanned: Tue, 16 Nov 2004 15:45:02 +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 iAGDj2P6009093; Tue, 16 Nov 2004 15:45:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00DmDTwI; Tue, 16 Nov 2004 15:44:52 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 iAGDioa15960; Tue, 16 Nov 2004 15:44:50 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 15:44:39 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 15:44:39 +0200 Received: esebe056.ntc.nokia.com 172.21.143.51 from 172.21.37.166 172.21.37.166 via HTTP with MS-WebStorage 6.0.6249 Received: from hed037-166.research.nokia.com by esebe056.ntc.nokia.com; 16 Nov 2004 15:44:37 +0200 Subject: Re: [Simple] Question about extending mood in rpids-04 From: Jari Urpalainen To: ext Paul Kyzivat In-Reply-To: <419217B5.6090903@cisco.com> References: <4190CA60.8080106@cisco.com> <4191BEFF.2090200@cisco.com> <419217B5.6090903@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1100612677.6605.33.camel@hed037-166.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 16 Nov 2004 15:44:37 +0200 X-OriginalArrivalTime: 16 Nov 2004 13:44:39.0827 (UTC) FILETIME=[6B686E30:01C4CBE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, simple@ietf.org, mikko.lonnfors@nokia.com, hgs@cs.columbia.edu, aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit On Wed, 2004-11-10 at 15:29, ext Paul Kyzivat wrote: > I am only asking the question as one who has no formal knowledge of xml. > Whatever is right with xml is fine with me. > > Paul > > Jonathan Rosenberg wrote: > > I had always assumed that if the entity validating the document didn't > > know about the extensions, the validation would proceed as if the > > unknown elements were part of the substitution group. However, I think > > that it is important for us to check this with folks who are more > > familiar with XML... > > > > -Jonathan R. > > > > Paul Kyzivat wrote: > > > >> Response near the end. > >> > >> Paul > >> > >> mikko.lonnfors@nokia.com wrote: > >> > >>>> mikko.lonnfors@nokia.com wrote: > >>>> > >>>>> > >>>>> > >>>>>> I'm wondering about the future proofness when using the > >>>>> > >>>>> > >>>>> > >>>> substitution > >>>> > >>>>>> groups. If the recipient is doing document validation, but doesn't > >>>>>> possess the extension schema, will it be able to validate the > >>>>>> document. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> As far as I understand, yes it can. > >>>> > >>>> > >>>> > >>>> Can you explain? If I receive a document that has an element I don't > >>>> understand, how can I tell it is an instance of a particular > >>>> substitution group if that is what is required for the document to > >>>> be valid? I decided to run some practical tests with xerces schema validator and it does what common sense says: if you extend abstract element with an element which does not have a definition within this schema it does not validate the document. All the examples that i have seen (e.g. xml schema best practises/schema primer) usually either import or include the previous schema and define some new elements with substitutionGroup in this new schema. So some kind of xml Schema versioning is thus needed if extension is being done with substitutionGroups. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 16 09:19: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 JAA01636; Tue, 16 Nov 2004 09:19:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4D0-0006Rp-D6; Tue, 16 Nov 2004 09:21:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU47q-0001PV-Oq; Tue, 16 Nov 2004 09:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU41G-0000OO-RP for simple@megatron.ietf.org; Tue, 16 Nov 2004 09:09:21 -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 JAA00828 for ; Tue, 16 Nov 2004 09:09:17 -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 1CU43T-0006EK-31 for simple@ietf.org; Tue, 16 Nov 2004 09:11:36 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 06:23:44 -0800 X-BrightmailFiltered: true 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 iAGE8gOx022226; Tue, 16 Nov 2004 06:08:43 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB46373; Tue, 16 Nov 2004 09:08:40 -0500 (EST) Message-ID: <419A09E8.7050400@cisco.com> Date: Tue, 16 Nov 2004 09:08:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom Subject: Re: [Simple] RE: Pseudo real time text transmission with SIMPLE References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA00828 Cc: "'Toip list'" , "'SIMPLE'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Gunnar Hellstrom wrote: > Yes, without considering usability aspects, and without considering int= eroperability > aspects, I just want to get some grip of how often the SIMPLE experts t= hink it is > reasonable for a UA to: You have to make a lot of assumptions to answer this, so there will be=20 no good answer in general. > 1. Send a SIP MESSAGE This is not supposed to be used for session mode type of usage, only for=20 a "page" mode. How often does it make sense to page someone? And how=20 many people might you want to page at a given time. In the short term, while sending out pages to a list of recipients, you=20 might be sending these as fast as you can. But over longer periods of=20 time I would expect the frequency to be one every several minutes or=20 even hours. This is for a UA supporting an individual user. A gateway or other=20 server could do almost anything. > 2. Send an MSRP SEND >=20 > 0.3 seconds, 0.5 seconds, 1 second, 2 seconds, 5 seconds, 10 seconds? >=20 > The payload would be 1 - 100 UTF-8 characters depending on the buffer t= ime and the > intensity of the sender. If you are talking about pure typing, then this could be about as often=20 as a user can type a line of text, over brief periods. But don't forget file transfer via MSRP - something we imagine it may=20 well be used for. Our usual example is tranferring the Lord of the Rings=20 video - I think the number is 5gb or something like that. From an=20 individual UA that isn't doing anything else, this could be done as a=20 single SEND, in which case the rate wouldn't be very high. If there are=20 other things going on, and sharing a connection to a relay, then it=20 might get chunked into 2k chunks. In that case, over a 10MB/S=20 connection, if I've done the arithmetic right, it could come to=20 1.6ms/send for this stream, plus an equal number for the other sends=20 that cause it to be chunked. But these aren't very realistic numbers on average. Paul > Gunnar > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 >=20 >>-----Original Message----- >>From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On >>Behalf Of Gregg Vanderheiden >>Sent: Monday, November 15, 2004 11:35 PM >>To: 'Gunnar Hellstrom'; 'SIMPLE' >>Cc: 'Toip list' >>Subject: RE: Pseudo real time text transmission with SIMPLE >> >> >>A fundamental question may be interoperability. >> >>If this is just 'effective text conversation while in another interacti= ve >>medium that involves voice conversation" then this would not come up. >> >>If this was "what will this group use for telephone equivalence" then i= t >>does. >> >>I can see however, how these two questions could be addressed separatel= y. >> >> >>Gregg >> >>-- ------------------------------ >>Gregg C Vanderheiden Ph.D. >>Professor - Ind. Engr. & BioMed Engr. >>Director - Trace R & D Center >>University of Wisconsin-Madison >> >> >>-----Original Message----- >>From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On Beh= alf >>Of Gunnar Hellstrom >>Sent: Monday, November 15, 2004 4:07 PM >>To: SIMPLE >>Cc: Toip list >>Subject: Pseudo real time text transmission with SIMPLE >> >>You remember the intensive discussion we had this summer about using SI= MPLE >>protocols for >>real time text transmission. >> >>Occasionally that idea pops up again. The benefit is said to be higher >>probability for >>mainstream implementation if the same protocol is reused for both messa= ging >>and real time. >> >>We decided before, that real time text transmission of the type we do w= ith >>RTP in RFC2793, >>with transmission at every 300 ms, is out of scope for SIMPLE. >> >>But what if we define a pseudo real time mode, e.g. transmitting at som= e >>seconds interval >>( when there is something to transmit), and also when the user has type= d a >>sentence >>delimiter. >> >>What are the feelings about suitable minimum transmission intervals in = a >>session from a >>network point of view: >> >>1. If SIP MESSAGE is used for the transmission? >> >>2. If MSRP directly between UA:s is used for the transmission? >> >>( For the moment not considering what the real time user feels about th= is >>kind of >>communication, that may be next question.) >> >>Regards >> >>Gunnar >> >>------------------------------------------- >>Gunnar Hellstr=F6m >>Omnitor AB >>Renathv=E4gen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >> >>- >>This list is maintained by Snowshore Networks - http://www.snowshore.co= m >>All comments on this list are the comments of the message originators a= nd >>Snowshore is not to be held responsible for any actions or comments fou= nd >>on this list. The archives for this list can be found at >>http://flyingfox.snowshore.com/toip_archive/maillist.html >> >> >>- >>This list is maintained by Snowshore Networks - http://www.snowshore.co= m >>All comments on this list are the comments of the message originators a= nd >>Snowshore is not to be held responsible for any actions or comments fou= nd >>on this list. The archives for this list can be found at >>http://flyingfox.snowshore.com/toip_archive/maillist.html >> >> >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 16 10:16: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 KAA06836; Tue, 16 Nov 2004 10:16:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU56D-0007nK-5k; Tue, 16 Nov 2004 10:18:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4vF-0004cB-Ht; Tue, 16 Nov 2004 10:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4m3-0008Ls-SX for simple@megatron.ietf.org; Tue, 16 Nov 2004 09:57: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 JAA04436 for ; Tue, 16 Nov 2004 09:57:38 -0500 (EST) Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4oH-0007IU-74 for simple@ietf.org; Tue, 16 Nov 2004 09:59:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Nov 2004 16:57:07 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B044E3F@rvil-mail.radvision.com> Thread-Topic: There seems to be a problem in ABNF of PRES URI Thread-Index: AcTL6Y2Osx/jm/AESAmYsqydFi5QeAAAu+8g From: "Tamar Barzuza" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Subject: [Simple] There seems to be a problem in ABNF of PRES URI X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable > Hi, >=20 > Where can I find an updated ABNF for SIP URI? > RFC 3861 sends me to RFCs 3859 and 2822, which brings me to the = (combined) ABNF: > PRES URI =3D "pres:" [ to ] [ headers ]=20 > to =3D mailbox=20 > mailbox =3D name-addr / addr-spec=20 > name-addr =3D [display-name] angle-addr=20 > angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr=20 > addr-spec =3D local-part "@" domain=20 > display-name =3D phrase=20 > headers =3D "?" header *( "&" header )=20 > header =3D hname "=3D" hvalue=20 >=20 > Which may lead to the following pres address: > pres: "Joe Schmo" ?subject=3Dquestion > Which reminds me more of a From header than of a uri. Moreover, when = put in a From header, this address will lead to nested information and = worst to nested angle brackets: > From: "Joe Schmo" = ?subject=3Dquestion> >=20 > Is there a mistake in the ABNF? > Moreover, in all the examples I could find, pres addresses take the = form "pres:user@example.com" which actually allows to compare them to = SIP URI. >=20 > Thanks, > Tamar. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 16 15:52:33 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 PAA11985; Tue, 16 Nov 2004 15:52:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUALn-0007gK-Uc; Tue, 16 Nov 2004 15:54:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAC9-0003Y5-GV; Tue, 16 Nov 2004 15:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUABh-0003JL-Hn for simple@megatron.ietf.org; Tue, 16 Nov 2004 15:44: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 PAA11129 for ; Tue, 16 Nov 2004 15:44:27 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUADy-0007WY-0z for simple@ietf.org; Tue, 16 Nov 2004 15:46:50 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2004 12:44:05 -0800 X-BrightmailFiltered: true 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 iAGKhrVx023893; Tue, 16 Nov 2004 12:43:53 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT91258; Tue, 16 Nov 2004 12:43:52 -0800 (PST) Message-ID: <419A6688.6050103@cisco.com> Date: Tue, 16 Nov 2004 15:43:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, bernhard.boehmer@siemens.com, simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Hi, > > Perhaps I've made things sound too complicated, so I try to clarify. > > The scenario which I'm thinking is such that the devices have open > SIP and presence APIs, on top of which third party developers are > able to create their own applications. For instance currently there > is a SIP stack for Symbian OS, and you can install variety of > SIP-based apps, such as push-to-talk, file sharing, battleship game, > voice IM etc. on top of it. Obviously there will in addition be the > "main" SIP UA that takes care of the core things such as voice, > video, MSRP and conferencing. > > Each of these applications is pretty independent of each other and > can't share capabilities with other apps. So what they need to do is > to publish their own individual tuples, which describe the > capabilities of that application only. Merging the tuples would give > the watchers a wrong idea ("battleship game with PTT suppport" etc.). > The applications can very well share the same SIP AoR, since they > sit on top of a common SIP stack, which can determine (in most cases) > the right application for the initial request based on e.g. caller > preferences, other header values, medias in SDP or whatever. This is the part that worries me. I really don't see how this is going to work in the general sense. GRUU would really help here; it would provide an identifiable URI for each of these different apps. The problem is that in SIP, the model is really that a user has a number of contacts against an AOR. When I call that AOR, any one of the contacts could service the request, albeit with perhaps a subset of the full capabilities that might get used. You are using SIP in a different model. Each contact of the AOR represents a different service. When I initiate communications, I can only be usefully connected to the service matching the one I am using to generate the request. That is, if I "call" you from my battleship app, that call has to get to your battleship app or it doesnt work. In this kind of model, I think these really represent different user agents which just happen to share a stack. I would go so far as to argue that you really want separate AOR for them altogether. Absent that, GRUU would clearly be the next best match. Otherwise, you are going to depend on some kind of magical dispatch based on what you *think* differentiates the INVITE from a battleship app with the INVITE from a PTT app. That seems incredibly brittle to me. > > The basic requirement is that these applications should be able to > control the authorization to the tuples _they_ publish. For instance > PTT app will have a white list to set who are able to see the PTT > related tuple(s). It is possible to have a common UI for this to > cover all apps, but app specific UIs will also contain authorization. > This further seems to argue for separate AORs/presentities for each of these, in fact. That said, the current authorization rules document allows for other selectors to be defined in the future which allow you to choose which services and tuples get advertised. Today, only two are defined for services - by URI scheme and by full URI. Other specs can define others in the future. I'd rather defer the definition of more complicated selectors to a follow on activity. > > > The requirements derived from this real life scenario are: 1. > Applications must be able to publish tuples using the SIP AoR as > their contact address in such way that the presence server won't > merge the tuples. -> Composition rules should allow multiple tuples > per AoR, and not override or merge them unless there is some explicit > indication on this. I'll say again that I think that this is a telling sign that you are dealing with different presentities. The fact that a compositor may decide to merge contacts for an AOR is explicitly because of this unstated notion that each contact for the AOR represens a valid reachable contact for a call to that AOR. Once you break that assumption, sure, composition doesn't work right anymore. My fear is that you actually have quite a different model for presence than in the current data model. You need to fix these inconsistencies at the root, rather than debtaing whether or not we should allow or disallow authorization based on capabilities or class. 2. Applications must be able to include enough > information in their tuples so that other similar applications can > identify them. -> Prescaps + proprietary capability elements is > enough. Service ID is not necessary. 3. Applications should be able > to create authorization rules that govern access to the tuples > published by them -> Some kind of static identifier for the tuples > used between PUA and PS would do. If nothing else is provided, at > least tuple ids should be then usable for authorization rules in > addition to contact URIs. Is this really an out-of-the-gate functionality that is needed? Markus wrote earlier: > Hi, > > I have thought about this a bit and my current thinking is this: - > Prescaps and other decomposed capabilities are good as long as your > application can interoperate with another application which only > supports a subset of your capabilities. In some cases this is clearly > useful, e.g. with different medias. - If you have a proprietary > application, which can ONLY work with another similar app, there is > no use in decomposing the capabilities. So for each this kind of app > you just define a single proprietary capability who is only > understood by other similar apps. - This type of proprietary app > should be published in a separate tuple of its own, and actually > SHOULD NOT included other capabilities. E.g. even if the app > supported voice, there is no point listing that, if it can't work > with another app that ONLY supports voice but not the proprietary > part. - On the other hand if you have an application which has a > certain proprietary capability, but that is not essential, you can > just include that in the tuple _in addition_ to all other > capabilities that you might have. The root cause problem here is that what you are describing is NOT sip. Thus, indicating it with a SIP URI isn't working for you. If it is not enough to just know the SIP URI, and you need some additional context because you won't interoperate if you don't support a feature, you are talking about a non-SIP protocol. I should be able to interoperate with any SIP endpoint given just the sip URI, assuming there is an overlap in media and codec. That is distinctly different from not interoperating because there is some non-standard logic in place. Thus, IMHO, if you want to indicate these non-SIP SIP protocols, please register a new URI scheme. For example, "ptt:" could be used to indicate the OMA PTT usage. Once you do this, scheme-based selection of tuples for authorization works fine. -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 Nov 16 18:34: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 SAA10388; Tue, 16 Nov 2004 18:34:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUCsK-0007BW-Fy; Tue, 16 Nov 2004 18:36:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUCg6-0001DP-5Y; Tue, 16 Nov 2004 18:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUCbi-0007iS-KN for simple@megatron.ietf.org; Tue, 16 Nov 2004 18:19:30 -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 SAA09061 for ; Tue, 16 Nov 2004 18:19:28 -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 1CUCdz-0006qd-OJ for simple@ietf.org; Tue, 16 Nov 2004 18:21:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 15:34:10 -0800 X-BrightmailFiltered: true 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 iAGNIPw0025197 for ; Tue, 16 Nov 2004 15:18:25 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFU04546; Tue, 16 Nov 2004 15:19:05 -0800 (PST) Message-ID: <419A8AE9.6090301@cisco.com> Date: Tue, 16 Nov 2004 18:19:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Subject: [Simple] diffs in xcap X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Folks, Based on discussion during the meeting, I have updated the core xcap spec to disallow idempotent requests which are idempotent using properties besides GET(PUT(x))=x. This change has showed up in the following places: Section 7, next to last paragprah before section 7.1. New paragraph reads: HTTP also specifies that PUT and DELETE requests are idempotent. This means that, if the client performs a PUT on a document and it succeeds, it can perform the same PUT, and the resulting document will look the same. Similarly, when a client performs a DELETE, if it succeeds, a subsequent DELETE to the same URL will generate a 404; the resource no longer exists on the server since it was deleted by the previous DELETE operation. To maintain this property, the client SHOULD construct its URLs such that, after the modification has taken place, the URL in the request will point to the resource just inserted for PUT (i.e., the body of the request), and will point to nothing for DELETE. If this property is maintained, it is the case that GET to the URL in the PUT will return the same content (i.e., GET(PUT(X)) == x). This property implies idempotency. Although a request can still be idempotent if it does not possess this property, XCAP does not permit such requests. If the client's request does not have this property, the server will reject the request with a 409 and indicate a cannot-insert error condition. Section 7.4, first full paragraph on page 24. New text: To be certain that element insertions have the GET(PUT(x))==x property, the client can check that the attribute predicates in the final path segment of the URL match the attributes of the element in the body of the request. As an example of an request that would not have this property and therefore not be idempotent, consider the following PUT request (URLs are line-folded for readability): Section 7.7, first full paragraph on page 26. New text: To be certain that attribute insertions have the GET(PUT(x))==x property, the client can check that any attribute predicate in the path segment that selects the element into which the attribute is inserted, matches a different attribute than the one being inserted by the request. As an example of a request that would not have this property and therefore not be idempotent, consider the following PUT request (URLs are line folded for readability): Section 8.2.3, fourth paragraph. New text: It is possible that the element cannot be inserted such that the request URI, when evaluated, returns the content provided in the request. Such a request is not allowed for PUT. This happens when the element in the body is not described by the expression in the target selector. An example of this case is described in . If this happens the server MUST NOT perform the insertion, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element. It is important to note that schema compliance does not play a role while performing the insertion. That is, the decision of where the element gets inserted is dictated entirely by the structure of the request-URI, the current document, and the rules in this specification. Section 10.1, definition of : This indicates that the requested PUT operation could not be performed because a GET of that resource after the PUT would not yield the content of the PUT request. (this was updated in the XML schema as well) The updated version with these changes can be found at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-05.txt which should appear in the archives shortly. This version also fixes a BNF bug which resulted in the production for AUID only containing a single character. 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 Wed Nov 17 04:15: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 EAA02552; Wed, 17 Nov 2004 04:15:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CULwp-0003Th-6j; Wed, 17 Nov 2004 04:17:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CULgv-0007Ak-64; Wed, 17 Nov 2004 04: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 1CULd3-0006hH-Pm for simple@megatron.ietf.org; Wed, 17 Nov 2004 03:57:30 -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 DAA00156 for ; Wed, 17 Nov 2004 03:57:27 -0500 (EST) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CULfR-0002pv-4g for simple@ietf.org; Wed, 17 Nov 2004 03:59:57 -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 iAH8vMF18622; Wed, 17 Nov 2004 10:57:25 +0200 (EET) X-Scanned: Wed, 17 Nov 2004 10:56: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 iAH8uZ1M003272; Wed, 17 Nov 2004 10:56:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00ED4t19; Wed, 17 Nov 2004 10:56:33 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 iAH8uVa20076; Wed, 17 Nov 2004 10:56:31 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 10:56:25 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 10:56:20 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] diffs in xcap Date: Wed, 17 Nov 2004 10:56:20 +0200 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8C6C@esebe056.ntc.nokia.com> Thread-Topic: [Simple] diffs in xcap Thread-Index: AcTMNOpehUK4BYx6S0KggjVi6rVjnAATgGow To: , X-OriginalArrivalTime: 17 Nov 2004 08:56:20.0904 (UTC) FILETIME=[4EDC0280:01C4CC83] X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable The changes below will be in the version of the draft that will be sent = to IESG. A WGLC for the whole draft will not be issued again. So, if you = have any comments about those changes, please speak up now and before = the end of the week. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 17.November.2004 01:19 > To: Simple WG > Subject: [Simple] diffs in xcap >=20 >=20 > Folks, >=20 > Based on discussion during the meeting, I have updated the core xcap=20 > spec to disallow idempotent requests which are idempotent using=20 > properties besides GET(PUT(x))=3Dx. This change has showed up in the=20 > following places: >=20 > Section 7, next to last paragprah before section 7.1. New=20 > paragraph reads: >=20 > HTTP also specifies that PUT and DELETE requests are > idempotent. This means that, if the client performs a PUT on a > document and it succeeds, it can perform the same PUT, and the > resulting document will look the same. Similarly, when a client > performs a DELETE, if it succeeds, a subsequent DELETE to the same URL > will generate a 404; the resource no longer exists on the server since > it was deleted by the previous DELETE operation. To maintain this > property, the client SHOULD construct its URLs such that, after the > modification has taken place, the URL in the request will point to the > resource just inserted for PUT (i.e., the body of the request), and > will point to nothing for DELETE. If this property is maintained, it > is the case that GET to the URL in the PUT will return the same > content (i.e., GET(PUT(X)) =3D=3D x). This property implies > idempotency. Although a request can still be idempotent if it does not > possess this property, XCAP does not permit such requests. If=20 > the client's > request does not have this property, the server will reject the > request with a 409 and indicate a cannot-insert error condition. >=20 >=20 > Section 7.4, first full paragraph on page 24. New text: >=20 > To be certain that element insertions have the GET(PUT(x))=3D=3Dx > property, the client can check that the attribute predicates in the > final path segment of the URL match the attributes of the element in > the body of the request. As an example of an request that would not > have this property and therefore not be idempotent, consider the > following PUT request (URLs are line-folded for readability): >=20 >=20 > Section 7.7, first full paragraph on page 26. New text: >=20 > To be certain that attribute insertions have the GET(PUT(x))=3D=3Dx > property, the client can check that any attribute predicate in the > path segment that selects the element into which the attribute is > inserted, matches a different attribute than the one being inserted by > the request. As an example of a request that would not have this > property and therefore not be idempotent, consider the following PUT > request (URLs are line folded for readability): >=20 > Section 8.2.3, fourth paragraph. New text: >=20 > It is possible that the element cannot be inserted such that the > request URI, when evaluated, returns the content provided in the > request. Such a request is not allowed for PUT. This happens when the > element in the body is not described by the expression in the target > selector. An example of this case is described in target=3D"sec:crel"/>. If this happens the server MUST NOT perform the > insertion, and MUST reject the request with a 409 response. The body > of the response SHOULD contain a detailed conflict report containing > the <cannot-insert> element. It is important to note that schema > compliance does not play a role while performing the insertion. That > is, the decision of where the element gets inserted is dictated > entirely by the structure of the request-URI, the current document, > and the rules in this specification. >=20 > Section 10.1, definition of : >=20 > This indicates that the = requested > PUT operation could not be performed because a GET of that resource > after the PUT would not yield the content of the PUT request. >=20 > (this was updated in the XML schema as well) >=20 >=20 >=20 > The updated version with these changes can be found at: > http://www.jdrosen.net/papers/draft-ietf-simple-xcap-05.txt >=20 > which should appear in the archives shortly. This version=20 > also fixes a=20 > BNF bug which resulted in the production for AUID only containing a=20 > single character. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 04:49: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 EAA05718; Wed, 17 Nov 2004 04:49:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMU3-0004Fv-1H; Wed, 17 Nov 2004 04:52:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMPR-0008N7-RE; Wed, 17 Nov 2004 04:47:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMIQ-0007Jc-LR for simple@megatron.ietf.org; Wed, 17 Nov 2004 04:40:23 -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 EAA05053 for ; Wed, 17 Nov 2004 04:40:12 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMKn-00045S-75 for simple@ietf.org; Wed, 17 Nov 2004 04:42:42 -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 iAH9dmv11853; Wed, 17 Nov 2004 11:39:49 +0200 (EET) X-Scanned: Wed, 17 Nov 2004 11:39:41 +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 iAH9df3R017861; Wed, 17 Nov 2004 11:39:41 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00zj5kCV; Wed, 17 Nov 2004 11:39:41 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 iAH9deS13470; Wed, 17 Nov 2004 11:39:40 +0200 (EET) Received: from [172.21.38.168] ([172.21.38.168]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 11:39:39 +0200 Message-ID: <419B1C5B.8060700@nokia.com> Date: Wed, 17 Nov 2004 11:39:39 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2004 09:39:39.0623 (UTC) FILETIME=[5BD10F70:01C4CC89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: SIMPLE mailing list Subject: [Simple] c= line in SDP for MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Ben: One more comment about the SDP usage of MSRP (section 8.1 of msrp-09). The draft correctly indicates that the port number in the m= line is ignored, since we have an msrp url in the a=path line. However, I didn't find any text indicating that the IP address contained in the c= line should also be ignored, because of the same reason. So I think there are two missing things: a) how an endpoint populates the hostname/IP address in the c= line. Here we may need to distinguish two cases: when the c= line is part of the session description (because it has to be a real hostname/IP address, since it may affect other media lines), and when the c= line is part of the media description (in this case the text should probably say, SHOULD NOT or MAY send, since it is going to be ignored). b) what to do at the receiving endpoint. This is easy, ignore. I hope you can get this comments into account. BR, 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 Wed Nov 17 05:14:33 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 FAA07990; Wed, 17 Nov 2004 05:14:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMs3-0004m3-PO; Wed, 17 Nov 2004 05:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMlV-0002dH-0h; Wed, 17 Nov 2004 05:10:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTobd-0007G0-GE; Mon, 15 Nov 2004 16:41: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 QAA13538; Mon, 15 Nov 2004 16:41:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTodi-0002pk-CS; Mon, 15 Nov 2004 16:43:58 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CToUD-00019P-Sp; Mon, 15 Nov 2004 16:34:09 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 15 Nov 2004 16:34:09 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Wed, 17 Nov 2004 05:10:16 -0500 Cc: simple@ietf.org Subject: [Simple] Last Call: 'Functional Description of Event Notification Filtering' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'Functional Description of Event Notification Filtering ' 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-11-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-03.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 05:16: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 FAA08180; Wed, 17 Nov 2004 05:16:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMuG-0004pL-Ed; Wed, 17 Nov 2004 05: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 1CUMlW-0002e8-Kp; Wed, 17 Nov 2004 05:10:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTobi-0007K6-Nc; Mon, 15 Nov 2004 16:41: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 QAA13564; Mon, 15 Nov 2004 16:41:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTodn-0002qC-DC; Mon, 15 Nov 2004 16:44:03 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CToVb-0004DK-VE; Mon, 15 Nov 2004 16:35:35 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 15 Nov 2004 16:35:35 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Wed, 17 Nov 2004 05:10:16 -0500 Cc: simple@ietf.org Subject: [Simple] Last Call: 'An Extensible Markup Language (XML) Based Format for Event Notification Filtering' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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) Based Format for Event Notification Filtering ' 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-11-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-03.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 05:18:35 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 FAA08340; Wed, 17 Nov 2004 05:18:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMvu-0004s2-Fo; Wed, 17 Nov 2004 05:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMlY-0002eh-F7; Wed, 17 Nov 2004 05:10:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTpRM-00024J-G6 for simple@megatron.ietf.org; Mon, 15 Nov 2004 17:35: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 RAA20272 for ; Mon, 15 Nov 2004 17:35:12 -0500 (EST) Received: from smtp.spamarrest.com ([66.150.163.174] helo=spamarrest.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTpTD-0004SI-Ee for simple@ietf.org; Mon, 15 Nov 2004 17:37:24 -0500 Received: from [128.104.192.100] (account vanderhe@smtp.spamarrest.com HELO NC6000BAK) by spamarrest.com (CommuniGate Pro SMTP 4.2b1) with ESMTP id 162116989; Mon, 15 Nov 2004 14:34:49 -0800 From: "Gregg Vanderheiden" To: "'Gunnar Hellstrom'" , "'SIMPLE'" Date: Mon, 15 Nov 2004 16:34:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcTLYdsEIBTQkpWnRuewC0y7HGB4xQAARxUA Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 17 Nov 2004 05:10:16 -0500 Cc: "'Toip list'" Subject: [Simple] RE: Pseudo real time text transmission with SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable A fundamental question may be interoperability. =20 If this is just 'effective text conversation while in another = interactive medium that involves voice conversation" then this would not come up.=20 If this was "what will this group use for telephone equivalence" then it does. I can see however, how these two questions could be addressed = separately.=20 =20 Gregg -- ------------------------------=20 Gregg C Vanderheiden Ph.D.=20 Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center=20 University of Wisconsin-Madison=20 -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com] On = Behalf Of Gunnar Hellstrom Sent: Monday, November 15, 2004 4:07 PM To: SIMPLE Cc: Toip list Subject: Pseudo real time text transmission with SIMPLE You remember the intensive discussion we had this summer about using = SIMPLE protocols for real time text transmission. Occasionally that idea pops up again. The benefit is said to be higher probability for mainstream implementation if the same protocol is reused for both = messaging and real time. We decided before, that real time text transmission of the type we do = with RTP in RFC2793, with transmission at every 300 ms, is out of scope for SIMPLE. But what if we define a pseudo real time mode, e.g. transmitting at some seconds interval ( when there is something to transmit), and also when the user has typed = a sentence delimiter. What are the feelings about suitable minimum transmission intervals in a session from a network point of view: 1. If SIP MESSAGE is used for the transmission? 2. If MSRP directly between UA:s is used for the transmission? ( For the moment not considering what the real time user feels about = this kind of communication, that may be next question.) Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators = and Snowshore is not to be held responsible for any actions or comments = found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/toip_archive/maillist.html _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 05:19:27 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 FAA08479; Wed, 17 Nov 2004 05:19:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMwm-0004tX-Qz; Wed, 17 Nov 2004 05:21:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMla-0002f9-Hf; Wed, 17 Nov 2004 05:10:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtX8-0001yQ-8u; Mon, 15 Nov 2004 21:57:30 -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 VAA11402; Mon, 15 Nov 2004 21:57:28 -0500 (EST) Received: from smtp-out-1002.amazon.com ([207.171.164.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtZC-000120-UW; Mon, 15 Nov 2004 21:59:42 -0500 Received: from smtp-in-1001.vdc.amazon.com by smtp-out-1002.amazon.com with ESMTP (peer crosscheck: smtp-in-1001.vdc.amazon.com) X-Amazon-Corporate-Relay: smtp-out-1002.vdc.amazon.com X-AMAZON-TRACK: ietf-announce@ietf.org Received: from ex-gate-01.ant.amazon.com by smtp-in-1001.vdc.amazon.com with ESMTP (crosscheck: ex-gate-01.ant.amazon.com [172.20.21.33]) id iAG2uoOP002544; Tue, 16 Nov 2004 02:56:51 GMT Received: from mail pickup service by ex-gate-01.ant.amazon.com with Microsoft SMTPSVC; Mon, 15 Nov 2004 18:56:50 -0800 Received: from mail-border-2006.iad2.amazon.com ([10.206.2.47]) by ex-gate-01.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Nov 2004 13:57:43 -0800 Received: from service-5-internal.amazon.com by mail-border-2006.iad2.amazon.com with SMTP (crosscheck: service-5-internal.amazon.com [10.16.42.51]) id iAFLv55f010759 for ; Mon, 15 Nov 2004 21:57:05 GMT X-Amazon-External-Source: yes X-Amazon-External-Envelope-Sender: ietf-announce-bounces@ietf.org Received: from patos.foghead.com ([192.147.160.6]) by service-5-internal.amazon.com via smtpd (for mail-border-2006.iad2.amazon.com [10.206.2.47]) with SMTP; 15 Nov 2004 21:57:05 UT Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by patos.foghead.com (8.12.10/8.12.10) with ESMTP id iAFLv30d060087 for ; Mon, 15 Nov 2004 13:57:03 -0800 (PST) (envelope-from ietf-announce-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTogC-0000jh-Er; Mon, 15 Nov 2004 16:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTobi-0007K6-Nc; Mon, 15 Nov 2004 16:41: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 QAA13564; Mon, 15 Nov 2004 16:41:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTodn-0002qC-DC; Mon, 15 Nov 2004 16:44:03 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CToVb-0004DK-VE; Mon, 15 Nov 2004 16:35:35 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 15 Nov 2004 16:35:35 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.15.2 X-AMAZON-GAUGE: IIIIIII X-OriginalArrivalTime: 15 Nov 2004 21:57:43.0266 (UTC) FILETIME=[22193C20:01C4CB5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Wed, 17 Nov 2004 05:10:16 -0500 Cc: simple@ietf.org Subject: [Simple] Last Call: 'An Extensible Markup Language (XML) Based Format for Event Notification Filtering' to Proposed Standard X-BeenThere: simple@ietf.org Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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) Based Format for Event Notification Filtering ' 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-11-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-03.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 06:24: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 GAA14209; Wed, 17 Nov 2004 06:24:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUNxP-0006HG-27; Wed, 17 Nov 2004 06:26:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUNnS-0000al-NZ; Wed, 17 Nov 2004 06:16:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUNky-00087O-IV for simple@megatron.ietf.org; Wed, 17 Nov 2004 06:13: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 GAA13427 for ; Wed, 17 Nov 2004 06:13:45 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUNnM-00063s-C7 for simple@ietf.org; Wed, 17 Nov 2004 06:16:17 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id DC378A9417 for ; Wed, 17 Nov 2004 12:13:14 +0100 (CET) Received: from [192.168.0.105] (b62-248-240-10.elisa-laajakaista.fi [62.248.240.10]) by voyager.coretrek.no (Postfix) with ESMTP id 6D8E9A9411 for ; Wed, 17 Nov 2004 12:13:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: simple@ietf.org From: Hisham Khartabil Date: Wed, 17 Nov 2004 12:13:06 +0100 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 1.3 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Simple] New Contact Details X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Hi, Please note the change in my email address. I will no longer read emails sent to my nokia account (but I might still send some from there). Please direct any email sent to me to this new email address that appears in the From-field. Regards, Hisham SIMPLE WG Co-chair _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 06:24: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 GAA14361; Wed, 17 Nov 2004 06:24:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUNyE-0006JM-Tv; Wed, 17 Nov 2004 06:27:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUNo6-0000pN-0H; Wed, 17 Nov 2004 06:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUNn3-0000Nn-C0 for simple@megatron.ietf.org; Wed, 17 Nov 2004 06:15: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 GAA13532 for ; Wed, 17 Nov 2004 06:15:54 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUNpN-00066m-CY for simple@ietf.org; Wed, 17 Nov 2004 06:18:26 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAHBFcF26460; Wed, 17 Nov 2004 13:15:39 +0200 (EET) X-Scanned: Wed, 17 Nov 2004 13:17:06 +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 iAHBH6Qp023359; Wed, 17 Nov 2004 13:17:06 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00b7IpPX; Wed, 17 Nov 2004 13:16:57 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 iAHBEiS24729; Wed, 17 Nov 2004 13:14:44 +0200 (EET) Received: from [172.21.34.165] ([172.21.34.165]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 13:14:38 +0200 Message-ID: <419B329D.9010601@nokia.com> Date: Wed, 17 Nov 2004 13:14:37 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: <419A6688.6050103@cisco.com> In-Reply-To: <419A6688.6050103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2004 11:14:38.0778 (UTC) FILETIME=[A0C719A0:01C4CC96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: hgs@cs.columbia.edu, pkyzivat@cisco.com, bernhard.boehmer@siemens.com, simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Inline. ext Jonathan Rosenberg wrote: > In this kind of model, I think these really represent different user > agents which just happen to share a stack. I would go so far as to argue > that you really want separate AOR for them altogether. Absent that, GRUU > would clearly be the next best match. Otherwise, you are going to depend > on some kind of magical dispatch based on what you *think* > differentiates the INVITE from a battleship app with the INVITE from a > PTT app. That seems incredibly brittle to me. What exactly is brittle in this? There are a ton of ways by which a helper application could register itself to such a dispatcher. The most obvious way is to give it an SDP to look for in incoming INVITES. Others include MIME types, feature tags, etc. Requiring any new application to have a separate AOR is an incredible barrier for innovation. Also, they simply don't work since I definitely don't want either service-specific AORs appearing on my business card, or GRUUs appearing in my call logs. I want to be contacted and contact people via a single, global, and lasting SIP address. ...snip... > The root cause problem here is that what you are describing is NOT sip. > Thus, indicating it with a SIP URI isn't working for you. If it is not > enough to just know the SIP URI, and you need some additional context > because you won't interoperate if you don't support a feature, you are > talking about a non-SIP protocol. I should be able to interoperate with > any SIP endpoint given just the sip URI, assuming there is an overlap in > media and codec. That is distinctly different from not interoperating > because there is some non-standard logic in place. I don't understand what this non-standard logic would be. If one of the parties in the call doesn't support ptt, then isn't that exactly a case where there is *not* an overlap in media and codec? I.e., business as usual. Certainly the rendezvous part of it at least is SIP. You can't be arguing against that; an unknown media/application doesn't make the protocol that carries such an offer non-SIP. > Thus, IMHO, if you want to indicate these non-SIP SIP protocols, please > register a new URI scheme. For example, "ptt:" could be used to indicate > the OMA PTT usage. Once you do this, scheme-based selection of tuples > for authorization works fine. Thinking beyond voice, video and MSRP, what new applications can there then actually be that I can use SIP for, and who decides that? I don't think we should be flooding IANA with URI scheme registrations just because we can't figure out handles in presence authorization beyond contact URI scheme. Email doesn't require a separate URI scheme for email and calendar invitations. Mailto is enough, because the clients know how to dispatch helper applications when they need to. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 09:24: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 JAA02320; Wed, 17 Nov 2004 09:24:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUQlv-00027t-Jg; Wed, 17 Nov 2004 09:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUQhX-0001hd-6z; Wed, 17 Nov 2004 09:22:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUQe7-00010J-Ti for simple@megatron.ietf.org; Wed, 17 Nov 2004 09:18: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 JAA02096 for ; Wed, 17 Nov 2004 09:18:54 -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 1CUQgX-00022P-DC for simple@ietf.org; Wed, 17 Nov 2004 09:21:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 06:31:34 -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 iAHEIFw0021329; Wed, 17 Nov 2004 06:18:15 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANC31722; Wed, 17 Nov 2004 09:18:18 -0500 (EST) Message-ID: <419B5DA8.90300@cisco.com> Date: Wed, 17 Nov 2004 09:18:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: <419A6688.6050103@cisco.com> <419B329D.9010601@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: hgs@cs.columbia.edu, bernhard.boehmer@siemens.com, simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Inline. > > ext Jonathan Rosenberg wrote: > >> In this kind of model, I think these really represent different user >> agents which just happen to share a stack. I would go so far as to argue >> that you really want separate AOR for them altogether. Absent that, GRUU >> would clearly be the next best match. Otherwise, you are going to depend >> on some kind of magical dispatch based on what you *think* >> differentiates the INVITE from a battleship app with the INVITE from a >> PTT app. That seems incredibly brittle to me. > > > What exactly is brittle in this? There are a ton of ways by which a > helper application could register itself to such a dispatcher. The most > obvious way is to give it an SDP to look for in incoming INVITES. Others > include MIME types, feature tags, etc. Well, suppose you establish your AOR this way. Then I send an INVITE to you without an offer. Are good things going to happen? I don't think so. Ideally this would result in a response with an offer of everything your device is capable of doing, so that the caller could choose what to do. > Requiring any new application to have a separate AOR is an incredible > barrier for innovation. Also, they simply don't work since I definitely > don't want either service-specific AORs appearing on my business card, > or GRUUs appearing in my call logs. I want to be contacted and contact > people via a single, global, and lasting SIP address *** Jonathan, please take note *** The above is an interesting point that we came across in private discussions last week. It is potentially a significant issue in using GRUUs as the targets for new outbound calls: call logs/histories/billing records will not have an address with long term significance. A month later when I am trying to decide what that call was about I may not be able to tell. Nor will I be able to call it back to find out. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 14:30: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 OAA02499; Wed, 17 Nov 2004 14:30:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVXe-0001Ez-2l; Wed, 17 Nov 2004 14:32:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVKc-0004Zw-72; Wed, 17 Nov 2004 14: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 1CUVGY-0003zr-MK for simple@megatron.ietf.org; Wed, 17 Nov 2004 14:14: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 OAA00812 for ; Wed, 17 Nov 2004 14:14:53 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVIy-0000s7-NK for simple@ietf.org; Wed, 17 Nov 2004 14:17:28 -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 iAHJEb719702; Wed, 17 Nov 2004 21:14:38 +0200 (EET) X-Scanned: Wed, 17 Nov 2004 21:14:16 +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 iAHJEG5U015286; Wed, 17 Nov 2004 21:14:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00oEQ4iE; Wed, 17 Nov 2004 21:14:15 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 iAHJEEa09558; Wed, 17 Nov 2004 21:14:14 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 21:14:15 +0200 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 21:14:12 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Question about extending mood in rpids-04 Date: Wed, 17 Nov 2004 21:14:13 +0200 Message-ID: Thread-Topic: [Simple] Question about extending mood in rpids-04 Thread-Index: AcTL4mqE1oJbiGxnS9e45hGfskm+FgA80zuw To: , X-OriginalArrivalTime: 17 Nov 2004 19:14:12.0706 (UTC) FILETIME=[9F601420:01C4CCD9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, simple@ietf.org, aki.niemi@nokia.com, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable > > >>>> Can you explain? If I receive a document that has an=20 > element I don't=20 > > >>>> understand, how can I tell it is an instance of a particular=20 > > >>>> substitution group if that is what is required for the=20 > document to=20 > > >>>> be valid? >=20 > I decided to run some practical tests with xerces schema validator and > it does what common sense says: if you extend abstract element with an > element which does not have a definition within this schema=20 > it does not > validate the document. All the examples that i have seen (e.g. xml > schema best practises/schema primer) usually either import or include > the previous schema and define some new elements with=20 > substitutionGroup > in this new schema. So some kind of xml Schema versioning is=20 > thus needed > if extension is being done with substitutionGroups. So, if I interpret this correctly the consequence of this is that if XML = document contains an extension to a substitution group all parties = trying to validate the XML document must understand the extension. If = the extension is not understood whole document is discarded. Using versioning is probably one way to solve this. However, this would = mean that we would need new MIME type for each version. Also, this may = lead into huge number of different versions. For example, if somebody = would define new SIP method using prescaps that would need a new = version. =20 I would propose the we implement extensibility using basic XML = mechanisms (using ##other or ##any declarations).=20 - Mikko =20 > br, > Jari > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 17 16:26: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 QAA18770; Wed, 17 Nov 2004 16:26:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXMd-0005ZW-Pl; Wed, 17 Nov 2004 16:29:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWvH-0001Uc-1g; Wed, 17 Nov 2004 16:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWfb-0001HG-HD; Wed, 17 Nov 2004 15:44:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10745; Wed, 17 Nov 2004 15:44:49 -0500 (EST) Message-Id: <200411172044.PAA10745@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 17 Nov 2004 15:44:49 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-05.txt Pages : 57 Date : 2004-11-17 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-17151007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-17151007.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From simple-bounces@ietf.org Wed Nov 17 22:30: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 WAA21254; Wed, 17 Nov 2004 22:30:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUd3D-0005n8-8M; Wed, 17 Nov 2004 22:33:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUcqy-0006xx-RZ; Wed, 17 Nov 2004 22:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUcq5-0006h7-T7 for simple@megatron.ietf.org; Wed, 17 Nov 2004 22:20: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 WAA20231 for ; Wed, 17 Nov 2004 22:20:03 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUcsd-0005Vg-2R for simple@ietf.org; Wed, 17 Nov 2004 22:22:43 -0500 Received: from razor.cs.columbia.edu (IDENT:Qlo/8ucs5XS50MiLDr1twSVVW65+S4ph@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAI3K1RX000044; Wed, 17 Nov 2004 22:20:02 -0500 (EST) Received: from [127.0.0.1] (IDENT:vjR7k5kTQT1hrvi4HyBSLf9Xbuq4kzAf@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAI3K1U3011106; Wed, 17 Nov 2004 22:20:01 -0500 Message-ID: <419C14DF.6000404@cs.columbia.edu> Date: Wed, 17 Nov 2004 22:19:59 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] Question about extending mood in rpids-04 References: In-Reply-To: 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.11.17.2 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: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit In a tangentially related vein, http://portal.opengis.org/files/?artifact_id=4347 covers related topics. It points out the practical problems of using substitutionGroup, alluding to the same issue as raised here. In addition, it notes on pg. 10 that "1. Many of the existing XML-Schema parsers do not fully support the XML-Schema specification and thus lack the ability to correctly process GML application schemas. 2. Most of the available XML-Schema parsers simply validate XML instance documents against XML-Schema documents. They lack the necessary API for interpreting XML-Schema document instances. 3. Typically, the only language binding available is Java. While it is possible to invoke Java routines from other languages using the Java Native Interface (JNI), this approach introduces another set of technical issues to deal with. Specifically, the parsers do not support substitution groups that are mandatory for processing GML schemas." It seems worrisome if we had to include XML schema verifiers in IM clients and if the simpler ones do not support the extension features we need. I don't think analogies with other applications (OASIS, say) are helpful, as these are generally used in fairly heavy-weight server applications that weigh in at hundreds of MB anyway. For the relatively straightforward token-level extensibility we need, it is not clear to me that we need to explore the outer edges of XML sophistication. Henning mikko.lonnfors@nokia.com wrote: > > So, if I interpret this correctly the consequence of this is that if > XML document contains an extension to a substitution group all > parties trying to validate the XML document must understand the > extension. If the extension is not understood whole document is > discarded. > > Using versioning is probably one way to solve this. However, this > would mean that we would need new MIME type for each version. Also, > this may lead into huge number of different versions. For example, if > somebody would define new SIP method using prescaps that would need a > new version. > > I would propose the we implement extensibility using basic XML > mechanisms (using ##other or ##any declarations). > > - Mikko > > >> br, Jari >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 18 06:03: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 GAA12788; Thu, 18 Nov 2004 06:03:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUk6w-0006dJ-Fu; Thu, 18 Nov 2004 06:05:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUk3I-00082h-1C; Thu, 18 Nov 2004 06:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUk1w-0007kZ-AH; Thu, 18 Nov 2004 06:00: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 GAA12642; Thu, 18 Nov 2004 06:00:45 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUk4W-0006Zu-Qg; Thu, 18 Nov 2004 06:03:30 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIB0fS28385; Thu, 18 Nov 2004 13:00:42 +0200 (EET) X-Scanned: Thu, 18 Nov 2004 13:00:22 +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 iAIB0Mm6002489; Thu, 18 Nov 2004 13:00:22 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00duk0wh; Thu, 18 Nov 2004 13:00:21 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 iAIB0LS29242; Thu, 18 Nov 2004 13:00:21 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 13:00:17 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 13:00:16 +0200 Received: esebe056.ntc.nokia.com 172.21.143.51 from 172.21.37.166 172.21.37.166 via HTTP with MS-WebStorage 6.0.6249 Received: from hed037-166.research.nokia.com by esebe056.ntc.nokia.com; 18 Nov 2004 13:00:14 +0200 Subject: Re: [Simple] Last Call: 'Functional Description of Event Notification Filtering' to Proposed Standard From: Jari Urpalainen To: iesg@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 18 Nov 2004 13:00:13 +0200 Message-Id: <1100775613.4002.17.camel@hed037-166.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 18 Nov 2004 11:00:16.0489 (UTC) FILETIME=[C939FD90:01C4CD5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit On Mon, 2004-11-15 at 16:34 -0500, ext The IESG wrote: > The IESG has received a request from the SIP for Instant Messaging and > Presence Leveraging Extensions WG to consider the following document: > > - 'Functional Description of Event Notification Filtering ' > 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-11-29. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-03.txt > Hi ! Some errors in the examples: In chapter 6.1.2 missing from the example. In Chapter 6.1.3 I'll propose /pidf:presence instead of //pidf:presence as is the root node of the document. In chapters 6.2.1, 6.2.2 and 6.2.3 wi-prefixes missing from values, e.g. /wi:watcherinfo/wi:watcherlist [@package="presence"]/wi:watcher... br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 18 15:01: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 PAA29063; Thu, 18 Nov 2004 15:01:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsVX-00024A-AD; Thu, 18 Nov 2004 15:03:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsNn-0001V3-Nl; Thu, 18 Nov 2004 14:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsDZ-0007K8-5o; Thu, 18 Nov 2004 14:45:21 -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 OAA25843; Thu, 18 Nov 2004 14:45:19 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsGF-0001ZY-0S; Thu, 18 Nov 2004 14:48:07 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id BD039A895E; Thu, 18 Nov 2004 20:44:47 +0100 (CET) Received: from [192.168.0.105] (b62-248-240-10.elisa-laajakaista.fi [62.248.240.10]) by voyager.coretrek.no (Postfix) with ESMTP id 6F791A93F4; Thu, 18 Nov 2004 20:44:46 +0100 (CET) In-Reply-To: <1100775613.4002.17.camel@hed037-166.research.nokia.com> References: <1100775613.4002.17.camel@hed037-166.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C855902-399A-11D9-BDB6-000D93C60BA0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Last Call: 'Functional Description of Event Notification Filtering' to Proposed Standard Date: Thu, 18 Nov 2004 20:44:45 +0100 To: Jari Urpalainen X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 1.3 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, iesg@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Thanks. Will Fix. Hisham On Nov 18, 2004, at 12:00 PM, Jari Urpalainen wrote: > On Mon, 2004-11-15 at 16:34 -0500, ext The IESG wrote: >> The IESG has received a request from the SIP for Instant Messaging and >> Presence Leveraging Extensions WG to consider the following document: >> >> - 'Functional Description of Event Notification Filtering ' >> 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-11-29. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter- >> funct-03.txt >> > Hi ! > > Some errors in the examples: > > In chapter 6.1.2 missing from the > example. > > In Chapter 6.1.3 I'll propose /pidf:presence instead of //pidf:presence > as is the root node of the document. > > In chapters 6.2.1, 6.2.2 and 6.2.3 wi-prefixes missing from > values, e.g. /wi:watcherinfo/wi:watcherlist > [@package="presence"]/wi:watcher... > > br, > Jari > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 18 16:34:53 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 QAA18022; Thu, 18 Nov 2004 16:34:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtyJ-0007Pv-1S; Thu, 18 Nov 2004 16:37:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtXF-0008FF-KZ; Thu, 18 Nov 2004 16:09:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsoK-0004Ll-3z; Thu, 18 Nov 2004 15:23: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 PAA02871; Thu, 18 Nov 2004 15:23:17 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsqz-0002mq-81; Thu, 18 Nov 2004 15:26:07 -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 iAIKNDb02504; Thu, 18 Nov 2004 22:23:14 +0200 (EET) X-Scanned: Thu, 18 Nov 2004 22:25:06 +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 iAIKP6PT028398; Thu, 18 Nov 2004 22:25:06 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00sjmfAO; Thu, 18 Nov 2004 22:25:04 EET Received: from [10.148.180.205] (essapo-nirac253155.europe.nokia.com [10.162.253.155]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIKMka28510; Thu, 18 Nov 2004 22:22:46 +0200 (EET) Message-ID: <419D0495.6080008@nokia.com> Date: Thu, 18 Nov 2004 22:22:45 +0200 From: jari urpalainen User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@telio.no Subject: Re: [Simple] Last Call: 'An Extensible Markup Language (XML) Based Format for Event Notification Filtering' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: iesg@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit ext The IESG wrote: >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) Based Format for Event Notification > Filtering ' > 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-11-29. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-03.txt > > Hi ! I am sorry for "late" comments (and this many). I'll have some performance concerns that servers may suffer from DoS attacks e.g. because of many conditions although they may well be quite useful in some cases. In order to minimize this I'll propose that at least examples avoid using anywhere "//" instead of absolute location paths that start from the document root. I would understand the semantics of and better if they were instead and . could only have XPath expressions because "namespace" could be presented as well with a request like *[namespace-uri()="urn:ietf:params:xml:ns:pidf"]. Then 'type' attribute could be removed. As unions "|" are also possible in XPath they could also be used instead of many or elements. element could be removed as elements could just be the first elements below . The "id" attribute could be of type xs:ID instead of xs:string. The meaning of the "remove" attribute is unclear to me, doesn't the client always send the full filtering document ? br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 18 23:18:36 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 XAA28032; Thu, 18 Nov 2004 23:18:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV0H3-0000Z2-82; Thu, 18 Nov 2004 23:21:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV0Bw-0001IL-7X; Thu, 18 Nov 2004 23:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV023-0007l1-2P for simple@megatron.ietf.org; Thu, 18 Nov 2004 23:05: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 XAA27064 for ; Thu, 18 Nov 2004 23:05:55 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV04n-0000JK-O3 for simple@ietf.org; Thu, 18 Nov 2004 23:08:49 -0500 Received: from razor.cs.columbia.edu (IDENT:2h+hE0wt9R6fARRRJVGhHvJ8sO4fBfBV@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ45sRX027070; Thu, 18 Nov 2004 23:05:55 -0500 (EST) Received: from [127.0.0.1] (IDENT:xoSIFq+seS+4veii+btdYkkzFwygafcN@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ45sU3026889; Thu, 18 Nov 2004 23:05:54 -0500 Message-ID: <419D711F.40702@cs.columbia.edu> Date: Thu, 18 Nov 2004 23:05:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: <419A6688.6050103@cisco.com> <419B329D.9010601@nokia.com> <419B5DA8.90300@cisco.com> In-Reply-To: <419B5DA8.90300@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.11.18.33 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: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > The above is an interesting point that we came across in private > discussions last week. It is potentially a significant issue in using > GRUUs as the targets for new outbound calls: call logs/histories/billing > records will not have an address with long term significance. A month > later when I am trying to decide what that call was about I may not be > able to tell. Nor will I be able to call it back to find out. To rephrase slightly: while there is a reasonably clear lifetime notion for Contact URIs returned under various conditions (within a dialog, permanent, etc.), this does not appear to be the case for GRUUs. The problem occurs in HTTP (the "bookmarking problem", typically due to embedding some state into the URI which is later no longer valid), but it remains annoying and puzzling to users. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 18 23:28:58 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 XAA28845; Thu, 18 Nov 2004 23:28:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV0R5-0000kg-Us; Thu, 18 Nov 2004 23:31:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV0K1-0003h7-Pv; Thu, 18 Nov 2004 23:24:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV0JG-0003Nf-6X for simple@megatron.ietf.org; Thu, 18 Nov 2004 23:23: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 XAA28373 for ; Thu, 18 Nov 2004 23:23:42 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV0M0-0000f2-V8 for simple@ietf.org; Thu, 18 Nov 2004 23:26:37 -0500 Received: from razor.cs.columbia.edu (IDENT:hfQFLLy/UQC9axKIOzFLqz035UPMcWsL@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ4NgRX000611; Thu, 18 Nov 2004 23:23:43 -0500 (EST) Received: from [127.0.0.1] (IDENT:uinWGeQ/0LOVFsQBL5dXtc1kif1FV5dZ@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ4NgU3026972; Thu, 18 Nov 2004 23:23:42 -0500 Message-ID: <419D754A.7070703@cs.columbia.edu> Date: Thu, 18 Nov 2004 23:23:38 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: In-Reply-To: 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.11.18.33 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_INTRO 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit I agree with the summary below. tuple-id's are also useful in authorizations particularly when the data and the rules are generated by the same (logical) entity, regardless of any AOR collision issues. Markus.Isomaki@nokia.com wrote: > Hi, > > Perhaps I've made things sound too complicated, so I try to clarify. > > The scenario which I'm thinking is such that the devices have open > SIP and presence APIs, on top of which third party developers are > able to create their own applications. For instance currently there > is a SIP stack for Symbian OS, and you can install variety of > SIP-based apps, such as push-to-talk, file sharing, battleship game, > voice IM etc. on top of it. Obviously there will in addition be the > "main" SIP UA that takes care of the core things such as voice, > video, MSRP and conferencing. > > Each of these applications is pretty independent of each other and > can't share capabilities with other apps. So what they need to do is > to publish their own individual tuples, which describe the > capabilities of that application only. Merging the tuples would give > the watchers a wrong idea ("battleship game with PTT suppport" etc.). > The applications can very well share the same SIP AoR, since they sit > on top of a common SIP stack, which can determine (in most cases) the > right application for the initial request based on e.g. caller > preferences, other header values, medias in SDP or whatever. > > The basic requirement is that these applications should be able to > control the authorization to the tuples _they_ publish. For instance > PTT app will have a white list to set who are able to see the PTT > related tuple(s). It is possible to have a common UI for this to > cover all apps, but app specific UIs will also contain authorization. > > > The requirements derived from this real life scenario are: 1. > Applications must be able to publish tuples using the SIP AoR as > their contact address in such way that the presence server won't > merge the tuples. -> Composition rules should allow multiple tuples > per AoR, and not override or merge them unless there is some explicit > indication on this. 2. Applications must be able to include enough > information in their tuples so that other similar applications can > identify them. -> Prescaps + proprietary capability elements is > enough. Service ID is not necessary. 3. Applications should be able > to create authorization rules that govern access to the tuples > published by them -> Some kind of static identifier for the tuples > used between PUA and PS would do. If nothing else is provided, at > least tuple ids should be then usable for authorization rules in > addition to contact URIs. We can use fixed tuple ids that persist > over time, although that is not exactly how those ids were meant to > be used. Another possibilty would be the class element, for which I > currently don't see any other use. > > I hope Jonathan could include this type of identifier (tuple id, > class, whatever) based tuple selection approach in the authorization > rules document. Otherwise it is difficult to support requirement 3. > > I don't think doing authorization based on capabilities is essential, > although it might be useful in some specific cases. > > Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 18 23:48: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 XAA00948; Thu, 18 Nov 2004 23:48:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV0jZ-0001DH-N1; Thu, 18 Nov 2004 23:50:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV0eM-0001V3-LZ; Thu, 18 Nov 2004 23:45:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV0Uv-0006sC-K1 for simple@megatron.ietf.org; Thu, 18 Nov 2004 23:35: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 XAA29565 for ; Thu, 18 Nov 2004 23:35:46 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV0Xf-0000uV-NG for simple@ietf.org; Thu, 18 Nov 2004 23:38:41 -0500 Received: from razor.cs.columbia.edu (IDENT:KBDG53EUnrpMp1McCJdLki2rt4/R3RPF@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ4YxRX003054; Thu, 18 Nov 2004 23:35:41 -0500 (EST) Received: from [127.0.0.1] (IDENT:wieUFPbVoUZONGnQ1bJFPzmTiiftELBl@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ4YxU3027015; Thu, 18 Nov 2004 23:34:59 -0500 Message-ID: <419D77EE.6010207@cs.columbia.edu> Date: Thu, 18 Nov 2004 23:34:54 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: <41993807.20408@cisco.com> In-Reply-To: <41993807.20408@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.11.18.33 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: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > OK. At least this is very clearly an OR-OF-ANDS presence representation > need, as opposed to the just conflicting views where one is right be we > don't know which one. I probably contributed to the confusion. I think the way to make sense of (service) tuples in general is to simply say that all of these are alternate services that can be used to reach the presentity. I'm not sure it's helpful to call out the same-AOR case, as even without this, it is a "or-of-and" enumeration across services. As I've tried to say before, even non-SIP URIs have never been sufficient to uniquely describe the precise service rendition by themselves. > I know that Henning is of the opinion that there is no need to > understand the difference between conflicting tuples and the OR-OF-ANDS > case, because they aren't operationally different to the end user. See above. I tried to unify the two notions (service enumeration, uncertainty) in my mind and at the microphone, but it didn't work well. This doesn't seem necessary, however. My main concern is not philosophy, but precisely defined watcher behavior. As long as we can precisely define what a watcher needs to do when it receives a list of service tuples, the data model is sufficiently well defined. Note that a presentity may intentionally give up fine-grained control of allowing certain UAs to control reaching service sub-entities in some cases. (If a browser doesn't support Accept-Language, the HTTP "URI overloading" mechanism isn't going to work well. This does not imply that we should abandon the mechanism.) > The AOR, with a uri parameter to distinguish the contacts, would also > work. However, with the exception of the grid parameter on gruus, you > can't count on uri parameters of an AOR being passed on when a request > is routed through the AOR to a registered contact. But if you are > content to use the AOR, because you discriminate on some other basis, > then maybe it doesn't matter to you that the parameter gets lost - it > will still serve to keep the tuples distinct. So maybe you could > populate your tuples with contacts like: > > or > As long as there is *something* that marks the tuples as being > different, it should be possible to construct an authorization rule that > is conditioned on that discriminating attribute. However, there may be > considerable difficulty in managing the collected set of rules after the > fact. How do you select the set of rules that belong to one application > so that it may edit them and not those of another application? Note that the GRUU doesn't really help any more than a tuple-id. Both are random and meaningless to third parties. In other words, if you want to select based on GRUUs, you have to still know which service description goes with that GRUU, presumably by subscribing to your own presence. Once you do that, you can also get the tuple ID. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 18 23:49: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 XAA01095; Thu, 18 Nov 2004 23:49:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV0kh-0001Fb-QS; Thu, 18 Nov 2004 23:52:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV0eZ-0001f6-LV; Thu, 18 Nov 2004 23:45:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV0ay-00005J-In for simple@megatron.ietf.org; Thu, 18 Nov 2004 23:42: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 XAA00177 for ; Thu, 18 Nov 2004 23:42:01 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV0dj-00013O-DN for simple@ietf.org; Thu, 18 Nov 2004 23:44:55 -0500 Received: from razor.cs.columbia.edu (IDENT:n0u475hMRs9SaTjcofg+JZhxGj1ukq87@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ4fKRX004192; Thu, 18 Nov 2004 23:42:01 -0500 (EST) Received: from [127.0.0.1] (IDENT:obiB3jWJKyCftQ2tguBk/Zr3wdtByqds@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iAJ4fKU3027028; Thu, 18 Nov 2004 23:41:20 -0500 Message-ID: <419D796B.5030705@cs.columbia.edu> Date: Thu, 18 Nov 2004 23:41:15 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: AW: AW: [Simple] Data model - attempt at summary References: <419A6688.6050103@cisco.com> In-Reply-To: <419A6688.6050103@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.11.18.33 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: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > The problem is that in SIP, the model is really that a user has a number > of contacts against an AOR. When I call that AOR, any one of the > contacts could service the request, albeit with perhaps a subset of the > full capabilities that might get used. > > You are using SIP in a different model. Each contact of the AOR > represents a different service. When I initiate communications, I can > only be usefully connected to the service matching the one I am using to > generate the request. That is, if I "call" you from my battleship app, > that call has to get to your battleship app or it doesnt work. Both models can work and, according to Markus, are being implemented. The question for us is not whether one is better than the other, but whether we should *disallow* Markus' model. Forcing distinct tuple URIs disallows the model. The services knows whether they need to publish distinct URIs or not. The watcher just does its thing, mechanically. Nobody prevents an entity from using GRUUs, individual contact URIs, service-based user names (alice+battleship@example.com, email style) or what have you. > That said, the current authorization rules document allows for other > selectors to be defined in the future which allow you to choose which > services and tuples get advertised. Today, only two are defined for > services - by URI scheme and by full URI. Other specs can define others > in the future. I'd rather defer the definition of more complicated > selectors to a follow on activity. Why not allow tuple-ids? Well-defined, even in PIDF and have no ambiguity whatsoever. Presumably, would be another selector. > The root cause problem here is that what you are describing is NOT sip. > Thus, indicating it with a SIP URI isn't working for you. If it is not > enough to just know the SIP URI, and you need some additional context > because you won't interoperate if you don't support a feature, you are > talking about a non-SIP protocol. I should be able to interoperate with > any SIP endpoint given just the sip URI, assuming there is an overlap in > media and codec. That is distinctly different from not interoperating > because there is some non-standard logic in place. > > Thus, IMHO, if you want to indicate these non-SIP SIP protocols, please > register a new URI scheme. For example, "ptt:" could be used to indicate > the OMA PTT usage. Once you do this, scheme-based selection of tuples > for authorization works fine. > > -Jonathan R. > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 19 16:49: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 QAA27753; Fri, 19 Nov 2004 16:49:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVGfs-00030Q-53; Fri, 19 Nov 2004 16:52:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVGMV-0004rh-BP; Fri, 19 Nov 2004 16:32:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVFdG-00061z-35 for simple@megatron.ietf.org; Fri, 19 Nov 2004 15:45: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 PAA14127 for ; Fri, 19 Nov 2004 15:45:23 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVFg9-0006rR-Ce for simple@ietf.org; Fri, 19 Nov 2004 15:48:25 -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 iAJKeECR017908; Fri, 19 Nov 2004 14:40:14 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 19 Nov 2004 14:39:03 -0600 Message-ID: From: "Nancy Greene (QC/EMC)" To: "'simple@ietf.org'" , "'ben@estacado.net'" , "'rohan@ekabal.com'" , "'fluffy@cisco.com'" Subject: RE: [Simple] MSRP: need for 202 Accepted status code? Date: Fri, 19 Nov 2004 14:37:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "Nancy Greene \(QC/EMC\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1954934609==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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. --===============1954934609== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CE77.A57120B0" 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_01C4CE77.A57120B0 Content-Type: text/plain; charset="iso-8859-1" In the same way that a SIP MESSAGE request can be answered with a 202 Accepted, a node implementing MSRP and acting on behalf of a recipient may not want to indicate successful delivery with 200 OK - it may just want to indicate it has accepted the message and will undertake to deliver it to the intended recipient. For this reason, I think that 202 Accepted should be listed in section 10 of the MSRP I-D as a valid status-code in REPORT. I don't think 202 is needed as a possible response code to MSRP SEND though. The one or more SENDs would have a "transaction status" of "200 OK", but then the "request status" could easily be "202 Accepted, and not yet delivered successfully". Do others agree with adding 202 Accepted as a possible "request status" in REPORT? Or is it expected that an interworking node would always wait for successful delivery from the other messaging system before returning a successful REPORT? Nancy -----Original Message----- From: Nancy Greene (QC/EMC) Sent: Thursday, November 11, 2004 7:50 PM To: simple@ietf.org Cc: Nancy Greene (QC/EMC) Subject: MSRP: need for 202 Accepted status code? When interworking with other messaging systems, it may be the case that the node doing the interworking doesn't actually know if the message has been successfully delivered. It just knows that the other system has taken over responsibility for delivering it. Perhaps then it would be good to allow a 202 Accepted status-code in REPORT. Nancy ------_=_NextPart_001_01C4CE77.A57120B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] MSRP: need for 202 Accepted status code?

In the same way that a SIP MESSAGE request can be = answered with a 202 Accepted, a node implementing MSRP and acting on = behalf of a recipient may not want to indicate successful delivery with = 200 OK - it may just want to indicate it has accepted the message and = will undertake to deliver it to the intended recipient.

For this reason, I think that 202 Accepted should be = listed in section 10 of the MSRP I-D as a valid status-code in REPORT. =

I don't think 202 is needed as a possible response = code to MSRP SEND though. The one or more SENDs would have a = "transaction status" of "200 OK", but then the = "request status" could easily be "202 Accepted, and not = yet delivered successfully".

Do others agree with adding 202 Accepted as a = possible "request status" in REPORT? Or is it expected that = an interworking node would always wait for successful delivery from the = other messaging system before returning a successful REPORT?

Nancy

-----Original Message-----
From: Nancy Greene (QC/EMC)
Sent: Thursday, November 11, 2004 7:50 PM
To: simple@ietf.org
Cc: Nancy Greene (QC/EMC)
Subject: MSRP: need for 202 Accepted status = code?


When interworking with other messaging systems, it = may be the case that the node doing the interworking doesn't actually = know if the message has been successfully delivered. It just knows that = the other system has taken over responsibility for delivering it. = Perhaps then it would be good to allow a 202 Accepted status-code in = REPORT.

Nancy


------_=_NextPart_001_01C4CE77.A57120B0-- --===============1954934609== 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 --===============1954934609==-- From simple-bounces@ietf.org Fri Nov 19 20:50: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 UAA17037; Fri, 19 Nov 2004 20:50:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVKRq-00081s-CK; Fri, 19 Nov 2004 20:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVKNY-0006he-UC; Fri, 19 Nov 2004 20:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVKMs-0006SY-6r for simple@megatron.ietf.org; Fri, 19 Nov 2004 20:48: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 UAA16906 for ; Fri, 19 Nov 2004 20:48:48 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVKPo-0007yZ-0k for simple@ietf.org; Fri, 19 Nov 2004 20:51:52 -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 iAK1mHVU065177 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 19 Nov 2004 19:48:18 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3EBC0A8E-3A96-11D9-8DE1-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: need for 202 Accepted status code? Date: Fri, 19 Nov 2004 19:48:15 -0600 To: "Nancy Greene (QC/EMC)" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: "'ben@estacado.net'" , "'rohan@ekabal.com'" , "'simple@ietf.org'" , "'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit The semantics for 200 in MSRP mean exactly that--the message has been accepted. It explicitly does not mean that the message has been delivered. What circumstances would you envision needing another code? On Nov 19, 2004, at 2:37 PM, Nancy Greene (QC/EMC) wrote: > In the same way that a SIP MESSAGE request can be answered with a 202 > Accepted, a node implementing MSRP and acting on behalf of a recipient > may not want to indicate successful delivery with 200 OK - it may just > want to indicate it has accepted the message and will undertake to > deliver it to the intended recipient. > > For this reason, I think that 202 Accepted should be listed in > section 10 of the MSRP I-D as a valid status-code in REPORT. > > I don't think 202 is needed as a possible response code to MSRP SEND > though. The one or more SENDs would have a "transaction status" of > "200 OK", but then the "request status" could easily be "202 Accepted, > and not yet delivered successfully". > > Do others agree with adding 202 Accepted as a possible "request > status" in REPORT? Or is it expected that an interworking node would > always wait for successful delivery from the other messaging system > before returning a successful REPORT? > > Nancy > > -----Original Message----- > From: Nancy Greene (QC/EMC) > Sent: Thursday, November 11, 2004 7:50 PM > To: simple@ietf.org > Cc: Nancy Greene (QC/EMC) > Subject: MSRP: need for 202 Accepted status code? > > > > When interworking with other messaging systems, it may be the case > that the node doing the interworking doesn't actually know if the > message has been successfully delivered. It just knows that the other > system has taken over responsibility for delivering it. Perhaps then > it would be good to allow a 202 Accepted status-code in REPORT. > > Nancy > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Nov 21 22:05: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 WAA23529; Sun, 21 Nov 2004 22:05:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW4Zk-0001wu-GI; Sun, 21 Nov 2004 22:09:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW4Uy-0006VK-2B; Sun, 21 Nov 2004 22:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW4Q8-0005P3-WB for simple@megatron.ietf.org; Sun, 21 Nov 2004 21:59: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 VAA22950 for ; Sun, 21 Nov 2004 21:59:15 -0500 (EST) Received: from kahuna.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW4TJ-0001nt-JQ for simple@ietf.org; Sun, 21 Nov 2004 22:02:45 -0500 X-Envelope-From: lisa@osafoundation.org X-Envelope-To: simple@ietf.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAM2wtZe011890 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 21 Nov 2004 18:58:58 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: HTTP working group , "'simple@ietf.org'" From: Lisa Dusseault Date: Sun, 21 Nov 2004 18:58:47 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Subject: [Simple] Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit 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. 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. 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. 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. 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 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). 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. 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? 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. Full disclosure: I'm partially responsible for the current design because I pointed out the write-through cache problem with a previous design that used query params in PUT URLs. Unfortunately, I think that on balance the problems with the current architecture are worse. Lisa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Nov 21 23:31: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 XAA29530; Sun, 21 Nov 2004 23:31:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW5uP-0003Mm-Gf; Sun, 21 Nov 2004 23:34:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW5oH-0000m8-Uf; Sun, 21 Nov 2004 23:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW5lj-0000TH-Hs for simple@megatron.ietf.org; Sun, 21 Nov 2004 23:25: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 XAA29137 for ; Sun, 21 Nov 2004 23:25:37 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW5p6-0003HS-2N for simple@ietf.org; Sun, 21 Nov 2004 23:29:09 -0500 Received: from [69.170.23.250] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8000482; Sun, 21 Nov 2004 23:25:25 -0500 Message-Id: <6.1.2.0.0.20041121232019.03c93918@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 21 Nov 2004 23:24:39 -0500 To: Lisa Dusseault , HTTP working group , "'simple@ietf.org'" From: "Joel M. Halpern" Subject: Re: [Simple] Some thoughts on XCAP's resource architecture In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 I am not sure I follow all of the concerns you are raising, and I could easily be missing some important point. However, we have implemented an XCAP server using an off-the-shelf HTTP server as a starting point. We did not have to do significant violence to the HTTP code to support XCAP, the XCAP granularity, or the XCAP dependency. (The places we had dependency issues had nothing to do with XCAP, but rather were simply that sometimes setting configuration information has side effects.) We probably could also handle it if the path were moved into the parameters. Hawever, the earlier discussion indicated that would not be a good idea. Moving the path into a different HTTP parameter would be a very bad idea from my perspective. It would be tantamount to treating HTTP as a transport for a non-HTTP protocol. The fact that I can currently use a standard browser to get XCAP information, and a browser with PUT support can be used to update information is a feature, and one we should try to preserve. Yours, Joel M. Halpern At 09:58 PM 11/21/2004, 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. 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 22 02:49: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 CAA27597; Mon, 22 Nov 2004 02:49:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW90b-00072X-0p; Mon, 22 Nov 2004 02:53:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW8rs-00066e-NB; Mon, 22 Nov 2004 02:44:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW8pc-0005Fw-9r for simple@megatron.ietf.org; Mon, 22 Nov 2004 02:41: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 CAA26924 for ; Mon, 22 Nov 2004 02:41:51 -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 1CW8t1-0006qk-Lj for simple@ietf.org; Mon, 22 Nov 2004 02:45:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2004 23:44:17 -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 iAM7fHw0003788; Sun, 21 Nov 2004 23:41:18 -0800 (PST) Received: from [10.0.0.125] (sjc-vpn2-471.cisco.com [10.21.113.215]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFW80539; Sun, 21 Nov 2004 23:41:17 -0800 (PST) Message-ID: <41A1981C.1060101@cisco.com> Date: Mon, 22 Nov 2004 02:41:16 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajesh Karunamurthy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA26924 Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: [Simple] Re: RFC 3856 - Fetching Mechanism X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable A fetch is done with a SUBSCRIBE with an Expires of zero seconds. This=20 results in a single NOTIFY containing the state of the resource. -Jonathan R. Rajesh Karunamurthy wrote: > Hi, >=20 > I have a small clarification regarding the fetching operation that coul= d=20 > be performed with subscription mechanism in RFC 3856. >=20 > The RFC tells that the SUBSCRIBE with an immediate expiration results i= n=20 > fetching of the presence information. What it exactly means by immediat= e=20 > time? Is it 5 seconds, 10 seconds, 30 seconds ?How is this fixed? >=20 > Let us assume that the rate of notification is 5 seconds. A user who is= =20 > not aware of the rate of notification time needs to fetch a presence=20 > document. He sends a subscribe request with 60 seconds, assuming its a= n=20 > "immediate " time. On the other hand the implemented system assumes tha= t=20 > user needs subscription for 60 seconds and sends 10-12 notifications.=20 > But this is not what the user expected. I think this is a possible=20 > scenario. How can this be handled ? Am i wrong? >=20 > If this is really a problem, the solution would be something like this.= =20 > The presence document is fetched once if the expiration time is lesser=20 > than the rate of notification time. If the expiration time is greater=20 > than rate of notification time the user gets subscribed and ofcourse th= e=20 > user can unsubscribe by sending the expiration time set to zero. >=20 > Am I wrong or missing out something? Please respond and advice me if I=20 > am out of track. >=20 > Thanks a lot, > Rajesh >=20 > _________________________________________________________________ > Designer Mail isn't just fun to send, it's fun to receive. Use special=20 > stationery, fonts and colors.=20 > http://join.msn.com/?pgmarket=3Den-ca&page=3Dbyoa/prem&xAPID=3D1994&DI=3D= 1034&SU=3Dhttp://hotmail.com/enca&HL=3DMarket_MSNIS_Taglines=20 > Start enjoying all the benefits of MSN=AE Premium right now and get th= e=20 > first two months FREE*. >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 22 12:41: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 MAA25342; Mon, 22 Nov 2004 12:41:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIEZ-0003jC-Am; Mon, 22 Nov 2004 12:44:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWHvq-0007O5-7V; Mon, 22 Nov 2004 12:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWHrk-0006cz-Q0 for simple@megatron.ietf.org; Mon, 22 Nov 2004 12: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 MAA21898 for ; Mon, 22 Nov 2004 12:20:37 -0500 (EST) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWHs9-0007Zg-AY for simple@ietf.org; Mon, 22 Nov 2004 12:21:05 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id iAMHG9Ae027097; Mon, 22 Nov 2004 11:16:09 -0600 (CST) Message-ID: <41A21ED8.9000703@alcatel.com> Date: Mon, 22 Nov 2004 11:16:08 -0600 From: Alex Audu 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 Subject: Re: [Simple] MSRP: need for 202 Accepted status code? References: <3EBC0A8E-3A96-11D9-8DE1-000D93B0AE1A@nostrum.com> In-Reply-To: <3EBC0A8E-3A96-11D9-8DE1-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "'ben@estacado.net'" , "'rohan@ekabal.com'" , "'simple@ietf.org'" , "'fluffy@cisco.com'" , "Nancy Greene \(QC/EMC\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alex.audu@alcatel.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit The message may have been accepted, but it hasn't yet been delivered. And in fact, it may still fail the interworking process. If an application depends on a successful end-to-end delivery of the message, then a 200 OK may be misleading in this case. I think we need something akin to CALL-PROGRESS code in the telco world,..something to indicate clearly, that though the message has been accepted, interworking is still going on. "202 Accepted and not yet delivered successfully" is a good idea in my view. Regards, Alex. Ben Campbell wrote: > The semantics for 200 in MSRP mean exactly that--the message has been > accepted. It explicitly does not mean that the message has been > delivered. What circumstances would you envision needing another code? > > On Nov 19, 2004, at 2:37 PM, Nancy Greene (QC/EMC) wrote: > >> In the same way that a SIP MESSAGE request can be answered with a 202 >> Accepted, a node implementing MSRP and acting on behalf of a >> recipient may not want to indicate successful delivery with 200 OK - >> it may just want to indicate it has accepted the message and will >> undertake to deliver it to the intended recipient. >> >> For this reason, I think that 202 Accepted should be listed in >> section 10 of the MSRP I-D as a valid status-code in REPORT. >> >> I don't think 202 is needed as a possible response code to MSRP SEND >> though. The one or more SENDs would have a "transaction status" of >> "200 OK", but then the "request status" could easily be "202 >> Accepted, and not yet delivered successfully". >> >> Do others agree with adding 202 Accepted as a possible "request >> status" in REPORT? Or is it expected that an interworking node would >> always wait for successful delivery from the other messaging system >> before returning a successful REPORT? >> >> Nancy >> >> -----Original Message----- >> From: Nancy Greene (QC/EMC) >> Sent: Thursday, November 11, 2004 7:50 PM >> To: simple@ietf.org >> Cc: Nancy Greene (QC/EMC) >> Subject: MSRP: need for 202 Accepted status code? >> >> >> >> When interworking with other messaging systems, it may be the case >> that the node doing the interworking doesn't actually know if the >> message has been successfully delivered. It just knows that the other >> system has taken over responsibility for delivering it. Perhaps then >> it would be good to allow a 202 Accepted status-code in REPORT. >> >> Nancy >> >> > > > > _______________________________________________ > 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 Nov 22 18:46: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 SAA07376; Mon, 22 Nov 2004 18:46:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWNwK-0001YR-H6; Mon, 22 Nov 2004 18:49:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWNpt-0001kx-2W; Mon, 22 Nov 2004 18:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWNly-0000qd-Gt for simple@megatron.ietf.org; Mon, 22 Nov 2004 18:39:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06644 for ; Mon, 22 Nov 2004 18:39:03 -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 1CWNpW-0000jv-3l for simple@ietf.org; Mon, 22 Nov 2004 18:42:46 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Nov 2004 16:44:09 +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 iAMNcKAC001213; Mon, 22 Nov 2004 15:38:21 -0800 (PST) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANF59069; Mon, 22 Nov 2004 18:38:27 -0500 (EST) Message-ID: <41A27872.9060304@cisco.com> Date: Mon, 22 Nov 2004 18:38:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com Subject: Re: [Simple] MSRP: need for 202 Accepted status code? References: <3EBC0A8E-3A96-11D9-8DE1-000D93B0AE1A@nostrum.com> <41A21ED8.9000703@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: "'fluffy@cisco.com'" , "'simple@ietf.org'" , "'rohan@ekabal.com'" , "'ben@estacado.net'" , "Nancy Greene \(QC/EMC\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Not only does the 200 already mean "accepted" or "received", but it only means it for the particular chunk of the whole message that it carries. We already have something else to indicate that the *whole* message has been processed. It is a success report for the whole message. Paul Alex Audu wrote: > The message may have been accepted, but it hasn't yet been delivered. > And in fact, it may still > fail the interworking process. If an application depends on a > successful end-to-end delivery of > the message, then a 200 OK may be misleading in this case. I think we > need something akin > to CALL-PROGRESS code in the telco world,..something to indicate > clearly, that though the > message has been accepted, interworking is still going on. "202 Accepted > and not yet delivered > successfully" is a good idea in my view. > > Regards, > Alex. > > > Ben Campbell wrote: > >> The semantics for 200 in MSRP mean exactly that--the message has been >> accepted. It explicitly does not mean that the message has been >> delivered. What circumstances would you envision needing another code? >> >> On Nov 19, 2004, at 2:37 PM, Nancy Greene (QC/EMC) wrote: >> >>> In the same way that a SIP MESSAGE request can be answered with a 202 >>> Accepted, a node implementing MSRP and acting on behalf of a >>> recipient may not want to indicate successful delivery with 200 OK - >>> it may just want to indicate it has accepted the message and will >>> undertake to deliver it to the intended recipient. >>> >>> For this reason, I think that 202 Accepted should be listed in >>> section 10 of the MSRP I-D as a valid status-code in REPORT. >>> >>> I don't think 202 is needed as a possible response code to MSRP SEND >>> though. The one or more SENDs would have a "transaction status" of >>> "200 OK", but then the "request status" could easily be "202 >>> Accepted, and not yet delivered successfully". >>> >>> Do others agree with adding 202 Accepted as a possible "request >>> status" in REPORT? Or is it expected that an interworking node would >>> always wait for successful delivery from the other messaging system >>> before returning a successful REPORT? >>> >>> Nancy >>> >>> -----Original Message----- >>> From: Nancy Greene (QC/EMC) >>> Sent: Thursday, November 11, 2004 7:50 PM >>> To: simple@ietf.org >>> Cc: Nancy Greene (QC/EMC) >>> Subject: MSRP: need for 202 Accepted status code? >>> >>> >>> >>> When interworking with other messaging systems, it may be the case >>> that the node doing the interworking doesn't actually know if the >>> message has been successfully delivered. It just knows that the other >>> system has taken over responsibility for delivering it. Perhaps then >>> it would be good to allow a 202 Accepted status-code in REPORT. >>> >>> Nancy >>> >>> >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 23 10:23: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 KAA20716; Tue, 23 Nov 2004 10:23:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcZD-0007Jn-Bl; Tue, 23 Nov 2004 10:26:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcOT-0006lU-9Y; Tue, 23 Nov 2004 10:15:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIsF-000106-OZ for simple@megatron.ietf.org; Mon, 22 Nov 2004 13:25: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 NAA29639 for ; Mon, 22 Nov 2004 13:25:13 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIvj-0000FN-TY for simple@ietf.org; Mon, 22 Nov 2004 13:28:53 -0500 Received: by rproxy.gmail.com with SMTP id b11so268017rne for ; Mon, 22 Nov 2004 10:25:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=XYMlGV1rwO+noIHMUJwNugsG5bQBAQI9Sb1818emDiAIMKn/GHwSCE94i1kCzlkDC1C8PHNRNXm4HWYCSVADwo3O3pvW07UntI3CCQqrHhSRvQQ6yxDLKxtQ2SP+g+9RvStFItCze5kzI7KfUoOF1Nj1euaZnPHqZxEaigP9b8Q= Received: by 10.38.72.71 with SMTP id u71mr964943rna; Mon, 22 Nov 2004 10:25:12 -0800 (PST) Received: by 10.38.151.28 with HTTP; Mon, 22 Nov 2004 10:25:12 -0800 (PST) Message-ID: <3f1451f504112210253425433a@mail.gmail.com> Date: Mon, 22 Nov 2004 13:25:12 -0500 From: Joe Gregorio To: Lisa Dusseault In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 23 Nov 2004 10:15:47 -0500 Cc: HTTP working group , "simple@ietf.org" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joe Gregorio List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit On Sun, 21 Nov 2004 18:58:47 -0800, 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. 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. This is just silly, HTTP is used to serve up everything from 100MB mpegs to a myriad of spacer GIFs. There is no such thing as a 'regular level of resource granularity' on the web. > 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). > > 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. > You are talking about implementation details, a choice on the part of the server writer. If you choose wrong, you may have difficulties, nothing earth-shattering there. -joe -- Joe Gregorio http://bitworking.org _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 23 10:23: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 KAA20743; Tue, 23 Nov 2004 10:23:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcZD-0007Jk-1e; Tue, 23 Nov 2004 10:27:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcOS-0006lH-I7; Tue, 23 Nov 2004 10:15:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgsG-00074m-IA for simple@megatron.ietf.org; Thu, 18 Nov 2004 02:38:36 -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 CAA25343 for ; Thu, 18 Nov 2004 02:38:34 -0500 (EST) Received: from bay15-f18.bay15.hotmail.com ([65.54.185.18] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgup-0002IY-AU for simple@ietf.org; Thu, 18 Nov 2004 02:41:16 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Nov 2004 23:38:02 -0800 Message-ID: Received: from 132.205.110.143 by by15fd.bay15.hotmail.msn.com with HTTP; Thu, 18 Nov 2004 07:37:53 GMT X-Originating-IP: [132.205.110.143] X-Originating-Email: [rajesh_karunamurthy@hotmail.com] X-Sender: rajesh_karunamurthy@hotmail.com From: "Rajesh Karunamurthy" To: simple@ietf.org Date: Thu, 18 Nov 2004 07:37:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 18 Nov 2004 07:38:02.0169 (UTC) FILETIME=[889BB290:01C4CD41] X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA25343 X-Mailman-Approved-At: Tue, 23 Nov 2004 10:15:47 -0500 Cc: jdrosen@dynamicsoft.com Subject: [Simple] RFC 3856 - Fetching Mechanism X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Hi, I have a small clarification regarding the fetching operation that could = be=20 performed with subscription mechanism in RFC 3856. The RFC tells that the SUBSCRIBE with an immediate expiration results in=20 fetching of the presence information. What it exactly means by immediate=20 time? Is it 5 seconds, 10 seconds, 30 seconds ?How is this fixed? Let us assume that the rate of notification is 5 seconds. A user who is n= ot=20 aware of the rate of notification time needs to fetch a presence document= .=20 He sends a subscribe request with 60 seconds, assuming its an "immediate= "=20 time. On the other hand the implemented system assumes that user needs=20 subscription for 60 seconds and sends 10-12 notifications. But this is no= t=20 what the user expected. I think this is a possible scenario. How can this= be=20 handled ? Am i wrong? If this is really a problem, the solution would be something like this. T= he=20 presence document is fetched once if the expiration time is lesser than t= he=20 rate of notification time. If the expiration time is greater than rate of= =20 notification time the user gets subscribed and ofcourse the user can=20 unsubscribe by sending the expiration time set to zero. Am I wrong or missing out something? Please respond and advice me if I am= =20 out of track. Thanks a lot, Rajesh _________________________________________________________________ Designer Mail isn't just fun to send, it's fun to receive. Use special=20 stationery, fonts and colors.=20 http://join.msn.com/?pgmarket=3Den-ca&page=3Dbyoa/prem&xAPID=3D1994&DI=3D= 1034&SU=3Dhttp://hotmail.com/enca&HL=3DMarket_MSNIS_Taglines=20 Start enjoying all the benefits of MSN=AE Premium right now and get the= =20 first two months FREE*. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 23 12:00:36 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 MAA00126; Tue, 23 Nov 2004 12:00:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWe5b-0003U6-Cf; Tue, 23 Nov 2004 12:04:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdyR-0000ww-4L; Tue, 23 Nov 2004 11:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdrV-0007dw-Tr for simple@megatron.ietf.org; Tue, 23 Nov 2004 11:49: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 LAA29265 for ; Tue, 23 Nov 2004 11:49:50 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdvC-0001sk-1H for simple@ietf.org; Tue, 23 Nov 2004 11:53:43 -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 iANGnZCR022201; Tue, 23 Nov 2004 10:49:35 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Nov 2004 10:48:13 -0600 Message-ID: From: "Nancy Greene (QC/EMC)" To: "'Paul Kyzivat'" , alex.audu@alcatel.com Subject: RE: [Simple] MSRP: need for 202 Accepted status code? Date: Tue, 23 Nov 2004 10:02:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "'ben@estacado.net'" , "'simple@ietf.org'" , "'fluffy@cisco.com'" , "'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1678393737==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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. --===============1678393737== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D175.D1606D6D" 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_01C4D175.D1606D6D Content-Type: text/plain; charset="iso-8859-1" Hi, Let me try again. Paul writes: >Not only does the 200 already mean "accepted" or "received", but it only >means it for the particular chunk of the whole message that it carries. > I know this. I said so in my original post. >We already have something else to indicate that the *whole* message has >been processed. It is a success report for the whole message. My point is that an interworking node may want to receive the whole message before even starting delivery to the final recipient. It needs to give some kind of report (in REPORT) back to the sender. I am proposing that if that interworking node cannot rightly say it has successfully delivered the message with a "report-status" of 200, we should allow that node to at least indicate it has accepted the message and will now attempt delivery. The report-status in REPORT that I propose is 202 Accepted. This would NEVER be sent as a response to an MSRP SENT. Nancy ------_=_NextPart_001_01C4D175.D1606D6D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] MSRP: need for 202 Accepted status code?

Hi, Let me try again.

Paul writes:
>Not only does the 200 already mean = "accepted" or "received", but it only
>means it for the particular chunk of the whole = message that it carries.
>
I know this. I said so in my original post.

>We already have something else to indicate that = the *whole* message has
>been processed. It is a success report for the = whole message.

My point is that an interworking node may want to = receive the whole message before even starting delivery to the final = recipient. It needs to give some kind of report (in REPORT) back to the = sender.

I am proposing that if that interworking node cannot = rightly say it has successfully delivered the message with a = "report-status" of 200, we should allow that node to at least = indicate it has accepted the message and will now attempt delivery. The = report-status in REPORT that I propose is 202 Accepted. This would = NEVER be sent as a response to an MSRP SENT.

Nancy

------_=_NextPart_001_01C4D175.D1606D6D-- --===============1678393737== 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 --===============1678393737==-- From simple-bounces@ietf.org Tue Nov 23 15:12: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 PAA17806; Tue, 23 Nov 2004 15:12:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWh4s-0003ns-Su; Tue, 23 Nov 2004 15:15:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgpt-000145-Af; Tue, 23 Nov 2004 15:00:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWggE-0005Rh-Hc for simple@megatron.ietf.org; Tue, 23 Nov 2004 14:50: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 OAA13156 for ; Tue, 23 Nov 2004 14:50: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 1CWgjw-0000kV-SP for simple@ietf.org; Tue, 23 Nov 2004 14:54:17 -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 iANJnpHO043947 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 23 Nov 2004 13:49:53 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: need for 202 Accepted status code? Date: Tue, 23 Nov 2004 13:49:45 -0600 To: "Nancy Greene (QC/EMC)" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: "'fluffy@cisco.com'" , "'rohan@ekabal.com'" , "'simple@ietf.org'" , "'ben@estacado.net'" , "'Paul Kyzivat'" , alex.audu@alcatel.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit There are to models to approach this with. One treats the gateway as if it were a relay. In this case, it would return a 200 response upon receiving the message, and depending on the report mode either return a report indicating it had _failed_ to deliver the message, or _not_ send a report indicating it had succeeded. The other model treats the gateway as an endpoint. The fact the gateway receives the message indicates the message was successfully delivered. If a downstream failure occurs, the gateway must use some other mechanism to report this. That mechanism is not in scope for MSRP. I don't see how either of these mechanisms benefit from a 202 code. The important thing is, a 200, either in a response or a REPORT, does _not_ indicate that the message has been seen by a human. It merely indicates that the message has been received by the device. It seems to me that the semantics you desire for 202 are identical. I can accept that we need some mechanism to indicate the final disposition of a message--but I think that work belongs elsewhere. On Nov 23, 2004, at 10:02 AM, Nancy Greene (QC/EMC) wrote: > Hi, Let me try again. > > Paul writes: > >Not only does the 200 already mean "accepted" or "received", but it > only > >means it for the particular chunk of the whole message that it > carries. > > > I know this. I said so in my original post. > > >We already have something else to indicate that the *whole* message > has > >been processed. It is a success report for the whole message. > > My point is that an interworking node may want to receive the whole > message before even starting delivery to the final recipient. It needs > to give some kind of report (in REPORT) back to the sender. > > I am proposing that if that interworking node cannot rightly say it > has successfully delivered the message with a "report-status" of 200, > we should allow that node to at least indicate it has accepted the > message and will now attempt delivery. The report-status in REPORT > that I propose is 202 Accepted. This would NEVER be sent as a response > to an MSRP SENT. > > Nancy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 23 17:31:52 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 RAA14032; Tue, 23 Nov 2004 17:31:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjGG-0001ZS-0g; Tue, 23 Nov 2004 17:35:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWj8S-0004An-RL; Tue, 23 Nov 2004 17: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 1CWiyM-0001Tt-UY for simple@megatron.ietf.org; Tue, 23 Nov 2004 17:17: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 RAA12840 for ; Tue, 23 Nov 2004 17:17:16 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWj27-00081O-00 for simple@ietf.org; Tue, 23 Nov 2004 17:21:11 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id iANMItuK015766 for ; Tue, 23 Nov 2004 15:18:55 -0700 (MST) Received: from il06exm13.corp.mot.com (il06exm13.corp.mot.com [10.0.111.13]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iANKGjdj008469 for ; Tue, 23 Nov 2004 14:16:45 -0600 Received: from bulb (bulb.corp.mot.com [10.14.25.99]) by il06exm13.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XH208NFX; Tue, 23 Nov 2004 16:17:15 -0600 Date: Tue, 23 Nov 2004 17:16:17 -0500 (EST) From: Srini Krishnamoorthy X-Sender: ksrini@bulb.corp.mot.com To: Rajesh Karunamurthy Subject: Re: [Simple] RFC 3856 - Fetching Mechanism In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ksrini@motorola.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Expires:0 in the SUBSCRIBE, does a immediate fetch (see 3.3.6 RFC3265) Notifiers are supposed to respond with a NOTIFY as soon as a SUBSCRIBE is received. -Srini On Thu, 18 Nov 2004, Rajesh Karunamurthy wrote: rajesh>Hi, rajesh> rajesh>I have a small clarification regarding the fetching operation that could be rajesh>performed with subscription mechanism in RFC 3856. rajesh> rajesh>The RFC tells that the SUBSCRIBE with an immediate expiration results in rajesh>fetching of the presence information. What it exactly means by immediate rajesh>time? Is it 5 seconds, 10 seconds, 30 seconds ?How is this fixed? rajesh> rajesh>Let us assume that the rate of notification is 5 seconds. A user who is not rajesh>aware of the rate of notification time needs to fetch a presence document. rajesh>He sends a subscribe request with 60 seconds, assuming its an "immediate " rajesh>time. On the other hand the implemented system assumes that user needs rajesh>subscription for 60 seconds and sends 10-12 notifications. But this is not rajesh>what the user expected. I think this is a possible scenario. How can this be rajesh>handled ? Am i wrong? rajesh> rajesh>If this is really a problem, the solution would be something like this. The rajesh>presence document is fetched once if the expiration time is lesser than the rajesh>rate of notification time. If the expiration time is greater than rate of rajesh>notification time the user gets subscribed and ofcourse the user can rajesh>unsubscribe by sending the expiration time set to zero. rajesh> rajesh>Am I wrong or missing out something? Please respond and advice me if I am rajesh>out of track. rajesh> rajesh>Thanks a lot, rajesh>Rajesh rajesh> rajesh>_________________________________________________________________ rajesh>Designer Mail isn't just fun to send, it's fun to receive. Use special rajesh>stationery, fonts and colors. rajesh>http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines rajesh> Start enjoying all the benefits of MSN(r) Premium right now and get the rajesh>first two months FREE*. rajesh> rajesh> rajesh>_______________________________________________ rajesh>Simple mailing list rajesh>Simple@ietf.org rajesh>https://www1.ietf.org/mailman/listinfo/simple rajesh> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 23 21:17: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 VAA03031; Tue, 23 Nov 2004 21:17:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWmmw-0005iw-Tj; Tue, 23 Nov 2004 21:21:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWmha-0001Mc-5H; Tue, 23 Nov 2004 21:16:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWmZh-00086n-7x for simple@megatron.ietf.org; Tue, 23 Nov 2004 21:08: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 VAA02409 for ; Tue, 23 Nov 2004 21:08:03 -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 1CWmdT-0004Wf-8D for simple@ietf.org; Tue, 23 Nov 2004 21:11:59 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2004 18:10:51 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAO27VYr027242; Tue, 23 Nov 2004 18:07:31 -0800 (PST) Received: from [10.32.131.11] ([10.32.131.11]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUG35134; Tue, 23 Nov 2004 18:07:31 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 23 Nov 2004 18:07:34 -0800 Subject: Re: [Simple] Some thoughts on XCAP's resource architecture From: Cullen Jennings To: Lisa Dusseault , HTTP working group , "simple@ietf.org" Message-ID: In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit On 11/21/04 6:58 PM, "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. 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. > I don't know much about web caches but I was just looking and it seems like one of the cisco content engines will do about 200 transactions per second. A company full of phones all powering up at the same time would overwhelm that pretty badly. > 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. > > 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'm not understanding here. How we can best design stuff to batch in a way to have optimal performance. > > 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 > > 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). In thinking about implementing something, it seems that XCAP would more or less require me to use a database not a file to manage this stuff. Perhaps someone like Joel or the Nokia folks who has actually implemented stuff can straighten me out. As the XCAP schemas get extended do I need to extend my DB schemas at the same time? Do I also need to extend server code to compute new things. > > 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. > I'm particularly interested in how much work it would be to turn something like, say Apache with a database behind it to store the data, into a xcap server? > 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? > > 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. > > Full disclosure: I'm partially responsible for the current design > because I pointed out the write-through cache problem with a previous > design that used query params in PUT URLs. Unfortunately, I think that > on balance the problems with the current architecture are worse. > > Lisa > > > _______________________________________________ > 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 Nov 24 10:08:20 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 KAA01577; Wed, 24 Nov 2004 10:08:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyoX-0004FP-GE; Wed, 24 Nov 2004 10:12:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWye3-0005Eb-UZ; Wed, 24 Nov 2004 10:01:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWybM-0003oa-A3 for simple@megatron.ietf.org; Wed, 24 Nov 2004 09:58:36 -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 JAA00005 for ; Wed, 24 Nov 2004 09:58:30 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyeq-00033a-Us for simple@ietf.org; Wed, 24 Nov 2004 10:02:33 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8019242; Wed, 24 Nov 2004 09:58:04 -0500 Message-Id: <6.1.2.0.0.20041124095206.03dd8ec0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 24 Nov 2004 09:57:52 -0500 To: HTTP working group , "simple@ietf.org" From: "Joel M. Halpern" Subject: Re: [Simple] Some thoughts on XCAP's resource architecture In-Reply-To: References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 I am not sure I follow the question here. Apologies if I am missing the point in attempting to answer. Whether the underlying data is stored in an XML document, an XML document plus indexing and related structures, a database, or something else entirely is a local implementation choice. I expect it to be influenced by the amount of related data to be handled, and by other product issues. (Similarly, with a web server, the question of whether resources are stored as HTML, stored as HTML fragments which are dynmically combined, fully dynamically generated, or some other mechanism is a local application dependent choice.) As for extension, it depends upon the problem. For what we are doing, extensions will occur only when the underlying system has new capabilities. And we will then extend the XML Schema. For some uses, being able to store uninterpretted but validated parts of the XML is important. In those cases, the schema provides for extension, and the XCAP server ought to be built so it can handle the data. Adding new features is going to mean adding capabilities to the parts that work with the server. Whether that requires updating the "database" probably depends upon the exact underlying implementation. The degree of change required has almost nothing to do with whether XCAP is used to communicate the configuration of the new features. Yours, Joel At 09:07 PM 11/23/2004, Cullen Jennings wrote: > > 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). > >In thinking about implementing something, it seems that XCAP would more or >less require me to use a database not a file to manage this stuff. Perhaps >someone like Joel or the Nokia folks who has actually implemented stuff can >straighten me out. As the XCAP schemas get extended do I need to extend my >DB schemas at the same time? Do I also need to extend server code to compute >new things. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 24 14:39: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 OAA22676; Wed, 24 Nov 2004 14:39:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX33U-0004G4-5P; Wed, 24 Nov 2004 14:43:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2xi-0008Ar-0Q; Wed, 24 Nov 2004 14:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2th-0007Qe-1H for simple@megatron.ietf.org; Wed, 24 Nov 2004 14:33: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 OAA22134 for ; Wed, 24 Nov 2004 14:33:47 -0500 (EST) Received: from kahuna.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2xb-00047E-S1 for simple@ietf.org; Wed, 24 Nov 2004 14:37:52 -0500 X-Envelope-From: lisa@osafoundation.org X-Envelope-To: simple@ietf.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAOJXXrG026070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 24 Nov 2004 11:33:41 -0800 In-Reply-To: References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Wed, 24 Nov 2004 11:33:26 -0800 To: "Alex Rousskov" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit We're actually on the same page about granularity. HTTP does not *define* a specific granularity, as you said (and as others have pointed out, many HTTP implementations are capable of handling a very small granularity). However since HTTP is one of the most widely deployed protocol systems we have, where browsers and intermediaries interact with a wide variety of servers and not just one host server, the practice matters as well as the definition. And the extensions that have been written to HTTP most definitely assume a larger granularity. I thought of another way to describe the resource granularity problem. When we say that something is "An HTTP Resource", here's what we imply (particularly for static, authorable resources): A resource can be queried for the current Entity Tag if the server supports ETags. A resource has its own last-modified timestamp, and supports the If-Modified-Since and If-Unmodified conditional headers. A resource has a Content-Type and a Content-Length, and may have an entity Digest (Content-MD5) A resource may be cacheable. You can ask an HTTP server what methods may be applied to a resource. A resource may be downloadable in byte-ranges. Hit-metering is typically measured per resource (see RFC2227 in particular) A resource has a set of queryable properties, including 'getetag', 'getlastmodified', 'creationdate' and 'getcontentype', if the server supports WebDAV. A resource can be locked (with its own independent lock token, lock owner) if the server supports WebDAV level 2. Each resource has its own lock info property. A resource can be moved with MOVE or copied with COPY if the server supports WebDAV. A resource supports the creation of user-defined properties if the server supports WebDAV. A 'diff' from a previously downloaded copy of a resource can be obtained if the server supports RFC3229. A resource may have a version history if the server supports RFC3253. A resource may have a "working copy" in another location if the server supports RFC3253. A resource may have a 'comment' property if the server supports RFC3253. A resource may be checked out and checked in if the server supports RFC3253. A resource may be given an ordering within a collection if the server supports RFC3648. A resource has its own access control list if the server supports RFC3744 (with any number of principals named in the list) Dynamic resources tend not to have all the same characteristics, but then they're not authorable. So when I look at what a resource is across all these HTTP extensions and in HTTP itself, and what XCAP wants to do, it seems to me that more often than not the XML document is the resource, and the XML node should simply be a part of that resource. We might think it would be nice to lock and add access control independently for every XML node but I don't think that will be manageable. Certainly the per-node version history seems prohibitive while the ability to view past versions of the whole document (and revert to a past version) seems potentially useful. That's what I mean by the granularity problem with extensions -- the choice of granularity for "what is a resource" has a lot of implications. Lisa On Nov 24, 2004, at 8:18 AM, Alex Rousskov wrote: > > On Sun, 2004/11/21 (MST), wrote: > >> 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 > > I disagree that HTTP defines some specific size and number of server > resources (what you define as resource granularity). From HTTP point > of view, URL paths are almost opaque. I agree that some server > implementations are less suitable than others to support XCAP, but I > do not see that as a showstopper. Will handling 1000 1-byte objects be > as efficient as handling 1 1000-byte object with HTTP? No, of course > not. However, handling 1000 1-byte objects may be efficient enough for > a given application/environment. And if some proxy breaks while > handling large number of small objects, that proxy is not HTTP > compliant and should be fixed (to prevent DoS attacks and such). > > I agree that HTTP assumes that resources are mostly independent. There > are no HTTP mechanisms to, say, invalidate a large group of resources > with a single response. However, individual applications and > environments can deal with it. For example, Apache provides > per-directory access controls. ICAP has ISTag header to invalidate all > cached responses from a given ICAP server at once. These examples do > not use HTTP features, but work fine on top of HTTP. Again, some > existing server implementations would be less appropriate for > supporting XCAP, but that should not be a showstopper for XCAP. > > $0.02, > > Alex. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 24 14:56:35 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 OAA23832; Wed, 24 Nov 2004 14:56:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3Jh-0004eK-2F; Wed, 24 Nov 2004 15:00:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3DN-0003yt-QU; Wed, 24 Nov 2004 14:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX38r-0002hc-Ka for simple@megatron.ietf.org; Wed, 24 Nov 2004 14:49: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 OAA23196 for ; Wed, 24 Nov 2004 14:49:27 -0500 (EST) Received: from kahuna.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3Cn-0004T8-79 for simple@ietf.org; Wed, 24 Nov 2004 14:53:33 -0500 X-Envelope-From: lisa@osafoundation.org X-Envelope-To: simple@ietf.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAOJnJrG026587 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 24 Nov 2004 11:49:21 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Simple] Some thoughts on XCAP's resource architecture Date: Wed, 24 Nov 2004 11:49:11 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: HTTP working group , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit >> 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'm not understanding here. How we can best design stuff to batch in a > way > to have optimal performance. 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). Similarly, even though a whole document may be large, up to a MB or so it's probably better to download (synch) the whole document rather than do several roundtrips to get individual nodes. Even though download requests can be pipelined not all client libraries support that yet. If you can pipeline, then you can do more node requests before the tradeoff of preferring to get the whole document kicks in. The optimal granularity for performance is probably somewhere between 1 kB and 10 MB for XCAP's use cases. A single XML node is probably too small; an undivisible 10 MB file is probably too large. Compare to byte ranges -- 10 MB files are often broken into byte ranges for reliable download, but the byte ranges aren't chosen to be too small or the performance cost would be greater than the reliability win. My size estimates here are from intuition based on experience; but I'm confident in saying that HTTP is not ideal for ferrying around tiny things at a high performance (just try using the MSDAIPP library to do client applications pretending that the HTTP server is a local database). The overhead per request/response is not insignificant. Since XCAP does allow addressable nodes to be grouped into larger addressable nodes it will be possible for a smart XCAP client to do some of this batching anyway, but many clients will do the simple and obvious thing regardless. So I don't expect this to be the killer argument for changing XCAP -- if this were the only consideration, the answer would likely be to "let the implementor beware". It's not the only consideration however -- I consider the implementability and interoperability of HTTP extensions to be the bigger consideration. Lisa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 24 19:28: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 TAA20514; Wed, 24 Nov 2004 19:28:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7Yw-0002X4-Ko; Wed, 24 Nov 2004 19:32:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX7Sv-0001QE-S1; Wed, 24 Nov 2004 19:26:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX7L1-00084l-Ov for simple@megatron.ietf.org; Wed, 24 Nov 2004 19:18: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 TAA19722 for ; Wed, 24 Nov 2004 19:18:16 -0500 (EST) Received: from kahuna.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7Op-0002Im-7H for simple@ietf.org; Wed, 24 Nov 2004 19:22:26 -0500 X-Envelope-From: lisa@osafoundation.org X-Envelope-To: simple@ietf.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAP0I4rG003037 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 24 Nov 2004 16:18:06 -0800 In-Reply-To: References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <72CCFDEA-3E77-11D9-B57F-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Wed, 24 Nov 2004 16:17:53 -0800 To: "Alex Rousskov" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit > >> A resource .... if the server supports WebDAV. > > I agree that editing some XCAP resources via WebDAV would be > difficult, but I think it would be still technically possible. Just do > not think of an XML document as a single file. Can you name a single > WebDAV feature that would be impossible to implement for most XCAP > resources? Nope, no impossibilities -- just difficulties and undesirabilities. >> We might think it would be nice to lock and add access control >> independently for every XML node but I don't think that will be >> manageable. > > Why not? If XML document is a collection of individually-managed > nodes, I do not see a problem. As a simple example, imagine a CGI > script that assembles an XML document from 100 nodes, each stored in > its own file. As a more flexible example, imagine an XML-friendly > database that allows users to have user-defined attributes for every > XML query result (which is nothing but a "view" in a database > terminology). It's manageable from a coding point of view, I'm sure we're all excellent coders. It's not manageable from an ease-of-use, application design and GUI point of view, nor does it scale as far. I really can't think how a GUI client/user can possibly manage all the ACLs on all the node resources -- the complexity is enormous if it's not scoped down somehow, and if it's not scoped down now, then the natural diversity of implementations will make it much harder to scope down later. Lisa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 25 03:35:21 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 DAA14931; Thu, 25 Nov 2004 03:35:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXFA3-0004sG-Nw; Thu, 25 Nov 2004 03:39:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEvl-00086u-CT; Thu, 25 Nov 2004 03:24:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXErt-00077P-QT for simple@megatron.ietf.org; Thu, 25 Nov 2004 03:20: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 DAA13600 for ; Thu, 25 Nov 2004 03:20:44 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXEvv-0004W9-Qg for simple@ietf.org; Thu, 25 Nov 2004 03:24:56 -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 iAP8Ke003529; Thu, 25 Nov 2004 10:20:41 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 10:23:04 +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 iAP8N4fe024582; Thu, 25 Nov 2004 10:23:04 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00i5lkk9; Thu, 25 Nov 2004 10:23:03 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 iAP8Joa22559; Thu, 25 Nov 2004 10:19:50 +0200 (EET) Received: from [172.21.37.161] ([172.21.37.161]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 10:19:38 +0200 Message-ID: <41A59599.5070700@nokia.com> Date: Thu, 25 Nov 2004 10:19:37 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Lisa Dusseault 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2004 08:19:38.0465 (UTC) FILETIME=[81687D10:01C4D2C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: HTTP working group , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Inline. ext Lisa Dusseault wrote: > 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. What you propose actually makes a lot of sense. We've concluded long ago, that in many ways, the XML document is the resource, and the node selector merely gives us the ability to point to sub-resources. As an example, there is only one etag for the full document, and it "magically" gets shared by all of the sub-resources. This is the implicit model already (even though XCAP URLs seem to be pointing to different resources), and making the change you propose would make things more explicit. Also, there is already a delimiter in the URL to separate document and node selectors, namely the double-tilde. Changing the delimiter to '?' is a minor change in syntax, IMO. One additional benefit in using a query string would be that it would enable a conditional append, which is currently kind of hard to do. That's because there is no etag to use in the If-Match, since the "resource" has never existed before. With the query string approach, the resource clearly would exist already, though the node selector would points to a non-existent element/attribute. > Full disclosure: I'm partially responsible for the current design > because I pointed out the write-through cache problem with a previous > design that used query params in PUT URLs. Unfortunately, I think > that on balance the problems with the current architecture are worse. I doubt that the write-through cache problem would turn out that serious in reality. These resources should anyway be accessed using transport security as well as authentication, and that should be clear enough signal to any mitm not to muck with the URLs. Cheers, Aki > > Lisa > > > _______________________________________________ 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 Nov 25 03:36:35 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 DAA15098; Thu, 25 Nov 2004 03:36:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXFBH-0004vM-AX; Thu, 25 Nov 2004 03:40:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXF4x-00026E-NR; Thu, 25 Nov 2004 03:34:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEu9-0007Zk-7W for simple@megatron.ietf.org; Thu, 25 Nov 2004 03:23: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 DAA13768 for ; Thu, 25 Nov 2004 03:23:03 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXEyA-0004aI-FS for simple@ietf.org; Thu, 25 Nov 2004 03:27:15 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAP8MwS13352; Thu, 25 Nov 2004 10:22:58 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 10:25:20 +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 iAP8PKA8031791; Thu, 25 Nov 2004 10:25:20 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00DSMmt0; Thu, 25 Nov 2004 10:25:19 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 iAP8MBa24752; Thu, 25 Nov 2004 10:22:12 +0200 (EET) Received: from [172.21.37.161] ([172.21.37.161]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 10:22:05 +0200 Message-ID: <41A5962B.80209@nokia.com> Date: Thu, 25 Nov 2004 10:22:03 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Joel M. Halpern" Subject: Re: [Simple] Some thoughts on XCAP's resource architecture References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <6.1.2.0.0.20041121232019.03c93918@localhost> In-Reply-To: <6.1.2.0.0.20041121232019.03c93918@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2004 08:22:05.0696 (UTC) FILETIME=[D92A2800:01C4D2C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault , HTTP working group , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Inline. ext Joel M. Halpern wrote: ...snip... > We probably could also handle it if the path were moved into the > parameters. Hawever, the earlier discussion indicated that would not be > a good idea. Moving the path into a different HTTP parameter would be a > very bad idea from my perspective. It would be tantamount to treating > HTTP as a transport for a non-HTTP protocol. The fact that I can > currently use a standard browser to get XCAP information, and a browser > with PUT support can be used to update information is a feature, and one > we should try to preserve. I agree that this is a very important feature to preserve. However, putting the node selector to a query string would preserve this property, as far as I can see. Putting it in an HTTP header clearly would not. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 26 16: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 QAA26638; Fri, 26 Nov 2004 16:50:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXo34-0000AA-Gd; Fri, 26 Nov 2004 16:54:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXnxR-00055p-3g; Fri, 26 Nov 2004 16:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXnv2-0004bw-40 for simple@megatron.ietf.org; Fri, 26 Nov 2004 16:46: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 QAA26451 for ; Fri, 26 Nov 2004 16:46:18 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXnzO-0008Ur-76 for simple@ietf.org; Fri, 26 Nov 2004 16:50:50 -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 iAQLkBIR072796 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 26 Nov 2004 15:46:12 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <41937A34.6060002@nokia.com> References: <41937A34.6060002@nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <968E85DE-3FF4-11D9-8B4D-000D93B0AE1A@nostrum.com> From: Ben Campbell Date: Fri, 26 Nov 2004 15:46:11 -0600 To: Miguel Garcia X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Simple WG Subject: [Simple] Re: Comments on IANA registration at MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122513321==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============2122513321== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-791803584; protocol="application/pkcs7-signature" --Apple-Mail-4-791803584 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I did a bit more research into the registration of "message", and find that the IANA sdp-parameters registry does not currently include media values. SDP-New proposes a registry for sdp media field values, and registers the "audio", "video", "text", and "application". Since "message" is a registered top-level MIME type, does it really make sense for MSRP to register it? It seems to me to make more sense to include it in sdp-new, if it is not to late to do so. Or does it make more sense for us to use "application" rather than "message"? On Nov 11, 2004, at 8:41 AM, Miguel Garcia wrote: > Hi: > > During the SIMPLE WG meeting we have a short discussion of the IANA > registration section in MSRP. Here are more detailed comments. I am > basing these comments on the IANA registration section of > draft-ietf-mmusic-sdp-new-21.txt Section 8.2.8, which contains > instructions for registration of SDP parameters. > > SDP defines the m= line with the following format: > > m= ... > > And a typical MSRP m= line in SDP looks like: > > m=message 9 msrp * > > > So the actions that are needed to the MSRP draft are: > > - MSRP needs to register "message" as a > > - MSRP needs to register "msrp" as a > > - Editorial: the registration text in Section 15.3 should follow the > template in sdp-new. This requires things like contact information, > one paragraph explanation, etc. > > Regards, > > Miguel > > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland --Apple-Mail-4-791803584 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAwwdSDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMjA0NTUyWhcNMDUwNDEyMjA0NTUyWjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFv8c1i8a9NXiEohMEryzypOcyz39k8PN WxTS4F45JSYwQ0/RAZ4vaemHCyJaUc7tc5DN3o7zl2oaqQuOIrvnjk79ILGJVfRgwt+uGDIGyaSM YmBeKXSdawFiJdk5jGtMzlgF8tzJzc4do5Mzl5YS39AR8mj8PF4zEgIlYYkKXBByHQ2jPA0qVfm/ Aj71RdYZyDAD4P7TyW9jKvZCl7KCfajar1llEQVj+kWMvt/3AE6mwAHXfkU7nL9XzLvGSnMUJvYx hq3UDju4IacXsYFw2oLb4LQdvwP4Lbg6qdp08h59+TkHlV6WNdt3ggM9C/cGQTDCa0CVJsr+76Dm mPorAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAApFAg5tsI2OhByoUglTZ+ip3M/1xfWDsCNsDB4+HtnH9fZfKkrkGp4e JQyuvl5VhvW67qYU6wEPMD0EKoWDU3v7l1huzR7Cpkf7n21y4LLG+VxldYiA3SEkv7RBPhhVhdMl sHwNZAYyVXFCdnvuVjfeytdAeXK6vzcaUvo9EwkHMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMHUgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDQxMTI2MjE0NjExWjAjBgkqhkiG9w0BCQQxFgQU7OqbjNMIm50u9tRj UjJAim2kC1sweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwwdSDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMHUgwDQYJKoZIhvcNAQEBBQAEggEALeAvbxeHo8XEOElp IHreMCelpWJYhTcWfYg+MwIRpi8X2VMiW0BsSAtIpwEWQitW6+iNtpCVZe9NX8964o6wq3o1AqCu 5mboEBDzfQ0rtI8RSdctT1x1QW0HapJazTM0U5FLLrHZEC6wrJ054is++y7kkxHLl8NfxW3ViUHh KShEEE5JylZSlQ4j/YZxNgeIKWpCEZJCAAFdBIXxyR1b2Z1U/gxbMUesxZs5xmVx+Imb0bulaokb GGhj7KxhlXpFdJ1MSerXW6mCVtUzYJvmEkM43G3q2pBrfdsFvPpnmrU0Oj++GxxliOed3Nl8NEGc NCNcQM9KnFO5EfFJx1I3ZAAAAAAAAA== --Apple-Mail-4-791803584-- --===============2122513321== 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 --===============2122513321==-- From simple-bounces@ietf.org Fri Nov 26 19:31:22 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 TAA12167; Fri, 26 Nov 2004 19:31:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXqZB-0006xY-0J; Fri, 26 Nov 2004 19:35:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXqR4-0008IW-76; Fri, 26 Nov 2004 19:27:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXqO3-0007rt-7l for simple@megatron.ietf.org; Fri, 26 Nov 2004 19:24: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 TAA11226 for ; Fri, 26 Nov 2004 19:24: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 1CXqSQ-0006b1-Ou for simple@ietf.org; Fri, 26 Nov 2004 19:28:59 -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 iAR0NPdn082743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Nov 2004 18:23:34 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41A7C8F5.6060302@nostrum.com> Date: Fri, 26 Nov 2004 18:23:17 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nancy Greene (QC/EMC)" Subject: Re: [Simple] MSRP: need for 202 Accepted status code? References: In-Reply-To: X-Enigmail-Version: 0.86.1.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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "'fluffy@cisco.com'" , "'rohan@ekabal.com'" , "'simple@ietf.org'" , "'ben@estacado.net'" , "'Paul Kyzivat'" , alex.audu@alcatel.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Nancy Greene (QC/EMC) wrote: > Hi, Let me try again. > > ... > > I am proposing that if that interworking node cannot rightly say it > has successfully delivered the message with a "report-status" of 200, > we should allow that node to at least indicate it has accepted the > message and will now attempt delivery. The report-status in REPORT > that I propose is 202 Accepted. This would NEVER be sent as a response > to an MSRP SENT. > I think what you're not quite understanding is that the MSRP 200 status code -- even when carried in REPORT messages -- *already* *means* the same thing as the 202 response code does in SIP. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 26 19:36: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 TAA12833; Fri, 26 Nov 2004 19:36:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXqeZ-0007Gk-9t; Fri, 26 Nov 2004 19:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXqZ1-0001qc-8c; Fri, 26 Nov 2004 19:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXqY8-0001ch-LM for simple@megatron.ietf.org; Fri, 26 Nov 2004 19:34: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 TAA12573 for ; Fri, 26 Nov 2004 19:34:49 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXqcV-00076j-F9 for simple@ietf.org; Fri, 26 Nov 2004 19:39:24 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 26 Nov 2004 16:35:32 -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-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAR0YVtR015384; Fri, 26 Nov 2004 16:34:32 -0800 (PST) Received: from [10.0.1.2] (sjc-vpn4-759.cisco.com [10.21.82.247]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUH64407; Fri, 26 Nov 2004 16:34:30 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 26 Nov 2004 16:34:35 -0800 Subject: Re: [Simple] MSRP: need for 202 Accepted status code? From: Cullen Jennings To: Adam Roach , "Nancy Greene (QC/EMC)" Message-ID: In-Reply-To: <41A7C8F5.6060302@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "'ben@estacado.net'" , Rohan Mahy , Paul H Kyzivat , alex.audu@alcatel.com, "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On 11/26/04 4:23 PM, "Adam Roach" wrote: > Nancy Greene (QC/EMC) wrote: > >> Hi, Let me try again. >> >> ... >> >> I am proposing that if that interworking node cannot rightly say it >> has successfully delivered the message with a "report-status" of 200, >> we should allow that node to at least indicate it has accepted the >> message and will now attempt delivery. The report-status in REPORT >> that I propose is 202 Accepted. This would NEVER be sent as a response >> to an MSRP SENT. >> > > I think what you're not quite understanding is that the MSRP 200 status > code -- even when carried in REPORT messages -- *already* *means* the > same thing as the 202 response code does in SIP. > > /a Would it be better if we used 202 in MSRP where we are currently using 200? Seems unlikely to me but I don't understand the difference between 202 and 200 in internet lore well enough to know. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 26 19:51: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 TAA14020; Fri, 26 Nov 2004 19:51:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXqsw-0007nI-H2; Fri, 26 Nov 2004 19:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXqjg-0003Ek-OS; Fri, 26 Nov 2004 19:46:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXqjO-00039c-Vt for simple@megatron.ietf.org; Fri, 26 Nov 2004 19:46: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 TAA13633 for ; Fri, 26 Nov 2004 19:46:28 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXqnl-0007e2-N4 for simple@ietf.org; Fri, 26 Nov 2004 19:51:03 -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 iAR0kQr7084336 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 26 Nov 2004 18:46:26 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Ben Campbell Subject: Re: [Simple] MSRP: need for 202 Accepted status code? Date: Fri, 26 Nov 2004 18:46:25 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Rohan Mahy , Adam Roach , "simple@ietf.org" , "'ben@estacado.net'" , Paul H Kyzivat , alex.audu@alcatel.com, "Nancy Greene \(QC/EMC\)" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1178835935==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 --===============1178835935== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-802618310; protocol="application/pkcs7-signature" --Apple-Mail-5-802618310 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 26, 2004, at 6:34 PM, Cullen Jennings wrote: > On 11/26/04 4:23 PM, "Adam Roach" wrote: > >> Nancy Greene (QC/EMC) wrote: >> >>> Hi, Let me try again. >>> >>> ... >>> >>> I am proposing that if that interworking node cannot rightly say it >>> has successfully delivered the message with a "report-status" of 200, >>> we should allow that node to at least indicate it has accepted the >>> message and will now attempt delivery. The report-status in REPORT >>> that I propose is 202 Accepted. This would NEVER be sent as a >>> response >>> to an MSRP SENT. >>> >> >> I think what you're not quite understanding is that the MSRP 200 >> status >> code -- even when carried in REPORT messages -- *already* *means* the >> same thing as the 202 response code does in SIP. >> >> /a > > Would it be better if we used 202 in MSRP where we are currently using > 200? > Seems unlikely to me but I don't understand the difference between 202 > and > 200 in internet lore well enough to know. > If we did, then 200 could go away, as it would get used. Actually, I think the problem is that people _expect_ these error codes to follow some "internet lore". They sort of mirror SIP for historical reasons. I am tempted to make them completely different than SIP, to avoid this sort of misunderstanding--but I think that would cause more disruption at this point that just dealing with misunderstandings. If nothing else, anyone who had done any implementation work would come after us with torches and pitchforks. 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. --Apple-Mail-5-802618310 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAwwdSDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMjA0NTUyWhcNMDUwNDEyMjA0NTUyWjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFv8c1i8a9NXiEohMEryzypOcyz39k8PN WxTS4F45JSYwQ0/RAZ4vaemHCyJaUc7tc5DN3o7zl2oaqQuOIrvnjk79ILGJVfRgwt+uGDIGyaSM YmBeKXSdawFiJdk5jGtMzlgF8tzJzc4do5Mzl5YS39AR8mj8PF4zEgIlYYkKXBByHQ2jPA0qVfm/ Aj71RdYZyDAD4P7TyW9jKvZCl7KCfajar1llEQVj+kWMvt/3AE6mwAHXfkU7nL9XzLvGSnMUJvYx hq3UDju4IacXsYFw2oLb4LQdvwP4Lbg6qdp08h59+TkHlV6WNdt3ggM9C/cGQTDCa0CVJsr+76Dm mPorAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAApFAg5tsI2OhByoUglTZ+ip3M/1xfWDsCNsDB4+HtnH9fZfKkrkGp4e JQyuvl5VhvW67qYU6wEPMD0EKoWDU3v7l1huzR7Cpkf7n21y4LLG+VxldYiA3SEkv7RBPhhVhdMl sHwNZAYyVXFCdnvuVjfeytdAeXK6vzcaUvo9EwkHMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMHUgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDQxMTI3MDA0NjI2WjAjBgkqhkiG9w0BCQQxFgQUtvr5/QiBnzpCvg7o EspewA+7VpgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwwdSDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMHUgwDQYJKoZIhvcNAQEBBQAEggEAbaVtWCPI6hwDyDRT FJ3H8pYbPZyrpAmumB9d3MD0aHFUQQ+FnoyzNtrDSgWw40XfnA2cDPJlwSiebtQ1DzBU861Ml2nL xSr1WJc/1CLSuEdZ13IaFdKIK4OeEX/zCsYESK+c8kAbGEAtvncVnijMVbJm2LvyBLK403fqTWr+ Bh71yfkHAzMKfBrOa3KCqjItVpEwbQTLDkGoQlLVuZzgO3xW2xYUfvx9aBvH9WxzZ8W+thHCeWHn DWZSOkLmJ6d4S/mvw4cxkRt6Zr3RIJ0Yr3uPiKUbJKfVQzo7hJ2AlTlFjTmFQCrCwLLbU7YluV2Z P5X/2Upr7u4ZYH0jQCIx9QAAAAAAAA== --Apple-Mail-5-802618310-- --===============1178835935== 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 --===============1178835935==-- From simple-bounces@ietf.org Sat Nov 27 20:30: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 UAA07317; Sat, 27 Nov 2004 20:30:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDy0-0002dY-FU; Sat, 27 Nov 2004 20:35:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDsO-0007hA-6P; Sat, 27 Nov 2004 20:29:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDrI-0007cK-SN for simple@megatron.ietf.org; Sat, 27 Nov 2004 20:28: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 UAA07144 for ; Sat, 27 Nov 2004 20:28:04 -0500 (EST) Received: from tk0008-202x210x243x26.ap-tk.usen.ad.jp ([202.210.243.26] helo=athena.ginganet.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDvP-0002Xu-Qz for simple@ietf.org; Sat, 27 Nov 2004 20:32:53 -0500 Received: by athena.ginganet.org (Postfix, from userid 5003) id 6D9E823CD1; Sun, 28 Nov 2004 10:27:22 +0900 (JST) Date: Sun, 28 Nov 2004 10:27:22 +0900 From: KAWAGUTI Ginga To: Lisa Dusseault Subject: Re: [Simple] Some thoughts on XCAP's resource architecture Message-ID: <20041128012722.GA49273%ginga@ginganet.org> References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: HTTP working group , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 In Sun, Nov 21, 2004 at 06:58:47PM -0800, Lisa Dusseault wrote: > 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. 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: ..snip.. > 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 agree with this in general. Also, there might be some other anxiety, which is encoding. XCAP's target document is usually written in UTF-8(it's XML), 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. 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. (People who lives in us-ascii world, or even iso-8859-* world, might not realize what these problems are...) -- Office: NTT Communications Innovative IP Architecture Center 1PT 1P Address: KAWAGUTI Ginga 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 Nov 29 07:04: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 HAA10743; Mon, 29 Nov 2004 07:04:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYkLX-00075a-HN; Mon, 29 Nov 2004 07:09:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkD8-00038I-V3; Mon, 29 Nov 2004 07:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYk4M-0000nB-VP for simple@megatron.ietf.org; Mon, 29 Nov 2004 06:51: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 GAA09877 for ; Mon, 29 Nov 2004 06:51:48 -0500 (EST) Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYk9G-0006qU-GQ for simple@ietf.org; Mon, 29 Nov 2004 06:56:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2004 13:51:19 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B044E56@rvil-mail.radvision.com> Thread-Topic: Mistake in PRES-URI BNF Thread-Index: AcTWCaDjM4FIQsWjTuS7Fjes8AVjBwAAAcpg From: "Tamar Barzuza" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Mistake in PRES-URI BNF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > Hi, >=20 > I found a problem in the BNF of PRES-URI. >=20 > RFC 2396 defined the generic syntax of URI. It explicitly says that = the following (delims) characters are disallowed within URI: > delims=3D "<" | ">" | "#" | "%" | <">=20 >=20 > However, in RFCs 3859 and 2822 the definition for PRES-URI is: > PRES URI =3D "pres:" [ to ] [ headers ]=20 > to =3D mailbox=20 > mailbox =3D name-addr / addr-spec=20 > name-addr =3D [display-name] angle-addr=20 > angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr=20 > addr-spec =3D local-part "@" domain=20 > display-name =3D phrase=20 > Which means that pres addresses can look like pres:"name", = hence may contain " and <>. >=20 > Therefore I believe that the PRES-URI BNF is mistaken.=20 >=20 > Thanks, > Tamar. >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 29 07:47: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 HAA14356; Mon, 29 Nov 2004 07:47:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYl0c-00084X-8t; Mon, 29 Nov 2004 07:52:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkgB-00017n-6i; Mon, 29 Nov 2004 07:30:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkdv-0000SF-Sp for simple@megatron.ietf.org; Mon, 29 Nov 2004 07:28:36 -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 EAA00266 for ; Mon, 29 Nov 2004 04:33:51 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYhzi-00045r-Ec for simple@ietf.org; Mon, 29 Nov 2004 04:38:55 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAT9Xlh5022819 for ; Mon, 29 Nov 2004 10:33:47 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 10:33:47 +0100 Received: from [147.214.34.68] (E-A75D10B0ED7B4.ki.sw.ericsson.se [147.214.34.68]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id X58K07TM; Mon, 29 Nov 2004 10:33:47 +0100 Message-ID: <41AAECFA.9080706@ericsson.com> Date: Mon, 29 Nov 2004 10:33:46 +0100 X-Sybari-Trust: 15dfd28a 87bd62f0 67bc480d 00000979 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Ben Campbell , Colin Perkins Subject: Re: [Simple] Re: Comments on IANA registration at MSRP References: <968E85DE-3FF4-11D9-8B4D-000D93B0AE1A@nostrum.com> In-Reply-To: <968E85DE-3FF4-11D9-8B4D-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2004 09:33:47.0251 (UTC) FILETIME=[86BE5C30:01C4D5F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi Ben, I think Colin Perkins will include "message" into the next version of SDP-new. I included him in this message so that he can verify it. Cheers Magnus Ben Campbell wrote: > > I did a bit more research into the registration of "message", and find > that the IANA sdp-parameters registry does not currently include media > values. SDP-New proposes a registry for sdp media field values, and > registers the "audio", "video", "text", and "application". > > Since "message" is a registered top-level MIME type, does it really > make sense for MSRP to register it? It seems to me to make more sense > to include it in sdp-new, if it is not to late to do so. > > Or does it make more sense for us to use "application" rather than > "message"? > -- 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 Nov 29 07:53: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 HAA15022; Mon, 29 Nov 2004 07:53:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYl6z-0008H6-If; Mon, 29 Nov 2004 07:58:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkh4-0001YJ-99; Mon, 29 Nov 2004 07:31:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkeY-0000WR-SB for simple@megatron.ietf.org; Mon, 29 Nov 2004 07:29:14 -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 DAA28122 for ; Mon, 29 Nov 2004 03:57:25 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYhQS-0003TB-4x for simple@ietf.org; Mon, 29 Nov 2004 04:02:29 -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 iAT8v5o25037; Mon, 29 Nov 2004 10:57:06 +0200 (EET) X-Scanned: Mon, 29 Nov 2004 10:56:47 +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 iAT8ulJD029266; Mon, 29 Nov 2004 10:56:47 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00E2nlsa; Mon, 29 Nov 2004 10:56:46 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 iAT8uja22282; Mon, 29 Nov 2004 10:56:45 +0200 (EET) Received: from [10.163.23.234] ([10.163.23.234]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Nov 2004 10:56:19 +0200 Message-ID: <41AAE435.3020503@nokia.com> Date: Mon, 29 Nov 2004 10:56:21 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell , Colin Perkins References: <41937A34.6060002@nokia.com> <968E85DE-3FF4-11D9-8B4D-000D93B0AE1A@nostrum.com> In-Reply-To: <968E85DE-3FF4-11D9-8B4D-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2004 08:56:19.0910 (UTC) FILETIME=[4B395660:01C4D5F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Comments on IANA registration at MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Probably it makes more sense that sdp-new registers the top-level "message" MIME type. Colin, since you are editing SDP-new, can you add the "message" registry to the next version? - Miguel Ben Campbell wrote: > I did a bit more research into the registration of "message", and find > that the IANA sdp-parameters registry does not currently include media > values. SDP-New proposes a registry for sdp media field values, and > registers the "audio", "video", "text", and "application". > > Since "message" is a registered top-level MIME type, does it really make > sense for MSRP to register it? It seems to me to make more sense to > include it in sdp-new, if it is not to late to do so. > > Or does it make more sense for us to use "application" rather than > "message"? > > On Nov 11, 2004, at 8:41 AM, Miguel Garcia wrote: > >> Hi: >> >> During the SIMPLE WG meeting we have a short discussion of the IANA >> registration section in MSRP. Here are more detailed comments. I am >> basing these comments on the IANA registration section of >> draft-ietf-mmusic-sdp-new-21.txt Section 8.2.8, which contains >> instructions for registration of SDP parameters. >> >> SDP defines the m= line with the following format: >> >> m= ... >> >> And a typical MSRP m= line in SDP looks like: >> >> m=message 9 msrp * >> >> >> So the actions that are needed to the MSRP draft are: >> >> - MSRP needs to register "message" as a >> >> - MSRP needs to register "msrp" as a >> >> - Editorial: the registration text in Section 15.3 should follow the >> template in sdp-new. This requires things like contact information, >> one paragraph explanation, etc. >> >> 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 Nov 30 09:34: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 JAA22048; Tue, 30 Nov 2004 09:34:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Ac-0004yd-7g; Tue, 30 Nov 2004 09:39:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zb-0008P6-Nb; Tue, 30 Nov 2004 09:28:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWzr5-0000t2-Pw for simple@megatron.ietf.org; Wed, 24 Nov 2004 11:18: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 LAA07185 for ; Wed, 24 Nov 2004 11:18:53 -0500 (EST) Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWzuz-0002kg-C4 for simple@ietf.org; Wed, 24 Nov 2004 11:22:57 -0500 Received: from pail.measurement-factory.com (nat.measurement-factory.com [206.168.0.3]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id iAOGInJ2055843; Wed, 24 Nov 2004 09:18:49 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Date: Wed, 24 Nov 2004 09:18:48 -0700 To: "Lisa Dusseault" , "HTTP working group" , "'simple@ietf.org'" References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> From: "Alex Rousskov" Organization: The Measurement Factory Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> User-Agent: Opera M2/7.54 (FreeBSD, build 751) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8bit On Sun, 2004/11/21 (MST), wrote: > 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 I disagree that HTTP defines some specific size and number of server resources (what you define as resource granularity). From HTTP point of view, URL paths are almost opaque. I agree that some server implementations are less suitable than others to support XCAP, but I do not see that as a showstopper. Will handling 1000 1-byte objects be as efficient as handling 1 1000-byte object with HTTP? No, of course not. However, handling 1000 1-byte objects may be efficient enough for a given application/environment. And if some proxy breaks while handling large number of small objects, that proxy is not HTTP compliant and should be fixed (to prevent DoS attacks and such). I agree that HTTP assumes that resources are mostly independent. There are no HTTP mechanisms to, say, invalidate a large group of resources with a single response. However, individual applications and environments can deal with it. For example, Apache provides per-directory access controls. ICAP has ISTag header to invalidate all cached responses from a given ICAP server at once. These examples do not use HTTP features, but work fine on top of HTTP. Again, some existing server implementations would be less appropriate for supporting XCAP, but that should not be a showstopper for XCAP. $0.02, Alex. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 09:36: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 JAA22202; Tue, 30 Nov 2004 09:36:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9CJ-00051m-Gm; Tue, 30 Nov 2004 09:41:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zc-0008PB-UY; Tue, 30 Nov 2004 09:28:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3DP-0003z0-9M for simple@megatron.ietf.org; Wed, 24 Nov 2004 14:54: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 OAA23632 for ; Wed, 24 Nov 2004 14:54:09 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3HK-0004a5-NP for simple@ietf.org; Wed, 24 Nov 2004 14:58:15 -0500 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by palrel10.hp.com (Postfix) with ESMTP id C0F991DB09; Wed, 24 Nov 2004 11:54:08 -0800 (PST) Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by hplms2.hpl.hp.com (8.13.1/8.13.1/HPL-PA Hub) with ESMTP id iAOJs6IH026586; Wed, 24 Nov 2004 11:54:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.10/8.12.9) with SMTP id iAOJs6VQ017341; Wed, 24 Nov 2004 11:54:06 -0800 (PST) From: Jeffrey Mogul Message-Id: <200411241954.iAOJs6VQ017341@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: Lisa Dusseault In-reply-to: Your message of "Wed, 24 Nov 2004 11:33:26 PST." X-Organization: Hewlett-Packard Labs, Large Scale Systems group Date: Wed, 24 Nov 2004 11:54:06 -0800 X-Mts: smtp X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Cc: HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 So when I look at what a resource is across all these HTTP extensions and in HTTP itself, and what XCAP wants to do, it seems to me that more often than not the XML document is the resource, and the XML node should simply be a part of that resource. We might think it would be nice to lock and add access control independently for every XML node but I don't think that will be manageable. Certainly the per-node version history seems prohibitive while the ability to view past versions of the whole document (and revert to a past version) seems potentially useful. That's what I mean by the granularity problem with extensions -- the choice of granularity for "what is a resource" has a lot of implications. I admit that I haven't been following this discussion in great depth. But when I read this paragraph, I thought that maybe the way to get at "node resources" is to treat them as a kind of "Range". Remember that the Range and Accept-Ranges headers in RFC2616 are not necessarily limited to byte ranges, although the spec is biased in that direction: 3.12 Range Units HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (section 14.35) and Content-Range (section 14.16) header fields. An entity can be broken down into subranges according to various structural units. range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = token The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges. One would hope that any extant implementation of Accept-Range is smart enough to ignore something *like* Accept-Ranges: xcap-nodes which would allow you to define a new specification for "ranges" of XCAP XML nodes that would be backwards compatible with HTTP/1.1. Then (if you pardon me for my complete ignorance of XCAP details) you could replace Lisa's example: http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ resource-lists/list%5b@name=%22friends%22%5d/entry with something like GET /services/resource-lists/users/bill/fr.xml/ HTTP/1.1 Host: xcap.example.com Range: xcap-nodes="resource-lists/list%5b@name=%22friends%22%5d/entry" with the obvious syntax if you wanted to get multiple nodes at once. Like I said, this could be totally naive. -Jeff _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 09:36: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 JAA22237; Tue, 30 Nov 2004 09:36:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Cs-00052J-1O; Tue, 30 Nov 2004 09:42:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8ze-0008ST-1O; Tue, 30 Nov 2004 09:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3m4-0003G0-Rc for simple@megatron.ietf.org; Wed, 24 Nov 2004 15:30:00 -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 PAA28702 for ; Wed, 24 Nov 2004 15:29:58 -0500 (EST) Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3px-0005ZS-7f for simple@ietf.org; Wed, 24 Nov 2004 15:34:04 -0500 Received: from pail.measurement-factory.com (nat.measurement-factory.com [206.168.0.3]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id iAOKTtJ2067332; Wed, 24 Nov 2004 13:29:55 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Date: Wed, 24 Nov 2004 13:29:54 -0700 To: "Lisa Dusseault" References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> From: "Alex Rousskov" Organization: The Measurement Factory Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (FreeBSD, build 751) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Cc: HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 8bit On Wed, 2004/11/24 (MST), wrote: > And the extensions that > have been written to HTTP most definitely assume a larger granularity. I am not sure that is true, let's go through your (edited) list : > A resource can be queried for the current Entity Tag if ... > A resource has its own last-modified timestampA resource has a > Content-Type and a Content-Length > A resource may have an entity Digest (Content-MD5) > A resource may be cacheable. > You can ask an HTTP server what methods may be applied to a resource. > A resource may be downloadable in byte-ranges. All of the above can still "work" when resource is a result of a query, IMO. Some servers will support some of the above features for XCAP, some will not. > Hit-metering is typically measured per resource Hit metering (as specified in IETF) is dead, but would still "work" for XCAP with post-processing scripts merging individual hit counters, for example; and nothing prevents folks specifying a "more XCAP-friendly" hit metering. > A resource .... if the server supports WebDAV. I agree that editing some XCAP resources via WebDAV would be difficult, but I think it would be still technically possible. Just do not think of an XML document as a single file. Can you name a single WebDAV feature that would be impossible to implement for most XCAP resources? > A 'diff' from a previously downloaded copy of a resource can be obtained > if ... > A resource may have a version history if ... > A resource may have a "working copy" in another location if ... > A resource may have a 'comment' property if ... > A resource may be checked out and checked in if ... > A resource has its own access control list if ... Again, all seem to be technically possible with XCAP resources, and not that difficult if XML storage model is more XML-friendly than a regular "file on disk". > A resource may be given an ordering within a collection if the server > supports RFC3648. Not sure about this one, but I think that some DTDs allow for any ordering of XML nodes inside an XML element, so perhaps the above is also applicable, in some environments. > So when I look at what a resource is across all these HTTP extensions > and in HTTP itself, and what XCAP wants to do, it seems to me that more > often than not the XML document is the resource, and the XML node should > simply be a part of that resource. That view is one of the many valid views, IMO. > We might think it would be nice to lock and add access control > independently for every XML node but I don't think that will be > manageable. Why not? If XML document is a collection of individually-managed nodes, I do not see a problem. As a simple example, imagine a CGI script that assembles an XML document from 100 nodes, each stored in its own file. As a more flexible example, imagine an XML-friendly database that allows users to have user-defined attributes for every XML query result (which is nothing but a "view" in a database terminology). > Certainly the per-node version history seems prohibitive Why? If my XML document is a collection of client information nodes, I can write an interface that will show per-client history of changes. > while the ability to view past versions of the whole document (and > revert to a past version) seems potentially useful. One does not preclude the other, I think. > That's what I mean by the granularity problem with extensions -- the > choice of granularity for "what is a resource" has a lot of implications. It seems to me that you have an "XML document is a file" assumption that is not true in general. Also, I am not sure we should attack one HTTP application based on what other HTTP applications or extensions can or cannot do. Each extension has its niche and they do not have to perfectly overlap all the time (otherwise, they should be included into the core protocol!). Thanks, Alex. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 09:38: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 JAA22336; Tue, 30 Nov 2004 09:38:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9EK-000541-JV; Tue, 30 Nov 2004 09:43:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8ze-0008SY-Pc; Tue, 30 Nov 2004 09:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5Ca-0007rU-FO for simple@megatron.ietf.org; Wed, 24 Nov 2004 17:01: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 RAA07937 for ; Wed, 24 Nov 2004 17:01:25 -0500 (EST) Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CX5GW-0007pC-Ht for simple@ietf.org; Wed, 24 Nov 2004 17:05:33 -0500 Received: (qmail 29257 invoked by uid 65534); 24 Nov 2004 22:00:54 -0000 Received: from pD95353FD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.83.253) by mail.gmx.net (mp001) with SMTP; 24 Nov 2004 23:00:54 +0100 X-Authenticated: #1915285 Message-ID: <41A50486.2080708@gmx.de> Date: Wed, 24 Nov 2004 23:00:38 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:33 -0500 Cc: Alex Rousskov , HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > We're actually on the same page about granularity. HTTP does not > *define* a specific granularity, as you said (and as others have pointed > out, many HTTP implementations are capable of handling a very small > granularity). However since HTTP is one of the most widely deployed > protocol systems we have, where browsers and intermediaries interact > with a wide variety of servers and not just one host server, the > practice matters as well as the definition. And the extensions that > have been written to HTTP most definitely assume a larger granularity. > > I thought of another way to describe the resource granularity problem. > When we say that something is "An HTTP Resource", here's what we imply > (particularly for static, authorable resources): > A resource can be queried for the current Entity Tag if the server > supports ETags. > A resource has its own last-modified timestamp, and supports the > If-Modified-Since and If-Unmodified conditional headers. > A resource has a Content-Type and a Content-Length, and may have an > entity Digest (Content-MD5) > A resource may be cacheable. Nit: it's not the resource that has etags and such, it's the resource's variants. The assumption that each resource has only a single variant in general is incorrect. > ... Best regards, Julian -- 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 Tue Nov 30 09:39: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 JAA22551; Tue, 30 Nov 2004 09:39:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Fa-000574-E9; Tue, 30 Nov 2004 09:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zf-0008Sd-Af; Tue, 30 Nov 2004 09:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5Tu-00035O-7N for simple@megatron.ietf.org; Wed, 24 Nov 2004 17:19: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 RAA08953 for ; Wed, 24 Nov 2004 17:19: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 1CX5Xq-00088m-0f for simple@ietf.org; Wed, 24 Nov 2004 17:23:26 -0500 Received: (qmail 24387 invoked by uid 65534); 24 Nov 2004 22:18:48 -0000 Received: from pD95353FD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.83.253) by mail.gmx.net (mp026) with SMTP; 24 Nov 2004 23:18:48 +0100 X-Authenticated: #1915285 Message-ID: <41A508C1.8070900@gmx.de> Date: Wed, 24 Nov 2004 23:18:41 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:33 -0500 Cc: HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Lisa Dusseault 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. I'd call that an implementation issue, not a problem with the design as such. You can avoid it by making responses non-cacheable, ot you can kick the vendor of the intermediary to fix the product (for instance, by modifying it not to cache very small entitities). > 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. , Section 8.5 seems to indicate that all subordinate resources of the document share the same etag, so this wouldn't be a problem. For instance, if you would view a subversion server as an XCAP server, the global revision number of the repository could be used as an etag. > 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. But it enables the client to decide on it's own. If latenty proves to be a problem, it can still update larger chunks in single requests. > 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 I disagree that these extensions have been designed with some specific particular granularity in mind (having been active member of the WQebDAV WG for the last 3,5 years and being one of the authors of RFC3744). > 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. But why is that a problem? It simply means that it's hard to adapt *specific* implementation for XCAP. > 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. That would IMHO be a problem anyway, because ETags *can't* work reliably if they are independant of each other if the server allows namespace operations. > - Since resources were independent, write requests for different > resources could be handled concurrently with ease, but that would have > to change. I think you're arguing from a very specific implementer's point of view. There are already WebDAV servers in place that handle XML in a similar way to XCAP (Slide/Tamino and (I think) Oracle10 come to mind). > 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? If two URLs map to the same underlying piece of data, they identify the same resource. Thus they would have the same ACLs. What am I missing? > 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. Putting the selector into the query part doesn't change anything it all. That would be merely a change in syntax with almost no impact in implementations (possibly except working around implementation problems in intermediaries). Putting it into separate headers would make the document fragments non-resources (not even second-class resources), thus I fail to see how that would be an improvement. You would simple have to reinvent a lot of syntax to do something that HTTP was already doing for you. > Full disclosure: I'm partially responsible for the current design > because I pointed out the write-through cache problem with a previous > design that used query params in PUT URLs. Unfortunately, I think that > on balance the problems with the current architecture are worse. Best regards, Julian -- 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 Tue Nov 30 09:40: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 JAA22629; Tue, 30 Nov 2004 09:40:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9GT-000582-2W; Tue, 30 Nov 2004 09:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zf-0008Si-UM; Tue, 30 Nov 2004 09:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5dM-00052q-1L for simple@megatron.ietf.org; Wed, 24 Nov 2004 17:29: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 RAA10216 for ; Wed, 24 Nov 2004 17:29:05 -0500 (EST) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CX5hI-0008QJ-IQ for simple@ietf.org; Wed, 24 Nov 2004 17:33:13 -0500 Received: (qmail 4073 invoked by uid 65534); 24 Nov 2004 22:28:35 -0000 Received: from pD95353FD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.83.253) by mail.gmx.net (mp017) with SMTP; 24 Nov 2004 23:28:35 +0100 X-Authenticated: #1915285 Message-ID: <41A50B0C.90109@gmx.de> Date: Wed, 24 Nov 2004 23:28:28 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> In-Reply-To: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:33 -0500 Cc: HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Lisa Dusseault 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. I'd call that an implementation issue, not a problem with the design as such. You can avoid it by making responses non-cacheable, ot you can kick the vendor of the intermediary to fix the product (for instance, by modifying it not to cache very small entitities). > 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. , Section 8.5 seems to indicate that all subordinate resources of the document share the same etag, so this wouldn't be a problem. For instance, if you would view a subversion server as an XCAP server, the global revision number of the repository could be used as an etag. > 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. But it enables the client to decide on it's own. If latenty proves to be a problem, it can still update larger chunks in single requests. > 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 I disagree that these extensions have been designed with some specific particular granularity in mind (having been active member of the WQebDAV WG for the last 3,5 years and being one of the authors of RFC3744). > 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. But why is that a problem? It simply means that it's hard to adapt *specific* implementation for XCAP. > 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. That would IMHO be a problem anyway, because ETags *can't* work reliably if they are independant of each other if the server allows namespace operations. > - Since resources were independent, write requests for different > resources could be handled concurrently with ease, but that would have > to change. I think you're arguing from a very specific implementer's point of view. There are already WebDAV servers in place that handle XML in a similar way to XCAP (Slide/Tamino and (I think) Oracle10 come to mind). > 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? If two URLs map to the same underlying piece of data, they identify the same resource. Thus they would have the same ACLs. What am I missing? > 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. Putting the selector into the query part doesn't change anything it all. That would be merely a change in syntax with almost no impact in implementations (possibly except working around implementation problems in intermediaries). Putting it into separate headers would make the document fragments non-resources (not even second-class resources), thus I fail to see how that would be an improvement. You would simple have to reinvent a lot of syntax to do something that HTTP was already doing for you. > Full disclosure: I'm partially responsible for the current design > because I pointed out the write-through cache problem with a previous > design that used query params in PUT URLs. Unfortunately, I think that > on balance the problems with the current architecture are worse. Best regards, Julian -- 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 Tue Nov 30 09:41:27 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 JAA22729; Tue, 30 Nov 2004 09:41:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9HD-000599-1r; Tue, 30 Nov 2004 09:46:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zh-0008Sn-Aj; Tue, 30 Nov 2004 09:28:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX7NW-0008Ti-2l for simple@megatron.ietf.org; Wed, 24 Nov 2004 19:20: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 TAA19796 for ; Wed, 24 Nov 2004 19:20:50 -0500 (EST) Received: from mail.shareable.org ([81.29.64.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7RT-0002Ld-Gg for simple@ietf.org; Wed, 24 Nov 2004 19:25:00 -0500 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id iAP0Ko81006533; Thu, 25 Nov 2004 00:20:50 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id iAP0KoAF006531; Thu, 25 Nov 2004 00:20:50 GMT Date: Thu, 25 Nov 2004 00:20:50 +0000 From: Jamie Lokier To: Julian Reschke Message-ID: <20041125002050.GA5730@mail.shareable.org> References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <41A508C1.8070900@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A508C1.8070900@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Cc: Lisa Dusseault , HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Julian Reschke wrote: > >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. > > Putting the selector into the query part doesn't change anything it all. > That would be merely a change in syntax with almost no impact in > implementations (possibly except working around implementation problems > in intermediaries). No, actually there is an important reason why XCAP should be changed to be after the query part. Clearly, generic origin XCAP servers should not have to analyse and transform the text of XML document - they should simply know how to select portions of it based on the XCAP selector. With the "/~~/" syntax, think about what happens when an XCAP resource is fetched by non-XCAP aware software that is given an XCAP URL. For example, a web browser told to view a subtree of some XML document. That is one of the most useful reasons why XCAP is operating using HTTP URLs, after all. Relative URLs appearing in the text of the subtree will be resolved by the browser including components of the selector. This is fine when the selector path represents other accessible resources. For example, when a selector is used to access resources in a filesystem-like hierarchy, but in this case, why use XCAP at all? However, imagine a browser is told to view some limited portion of an XHTML document (or any other document format), which contains links to other resources on the same server. In this case, the URL is used to restrict the view of the document to a portion of it. When XCAP is used in this way, almost certainly you want URLs in the text of the restricted view to resolve relative to the path _before_ the selector - the selector itself should not count in relative URL resolution. To fix this, thereby making XCAP more widely useful, why not use "??": - "??" seems likely to be unambiguous in practice - it's valid, and RFC1808 path resolvers will do the right thing - it can be appended to any existing path including those which already have a "?" query part, so select sub-resources of all existing resources "??" would allow a generic XCAP server module to be written which would serve a restricted view of _any_ resource that the server already serves, automatically maintaining correct relative URLs in the resource whatever its syntax. For example, such a module could be written for Apache, and it would automatically add a facility for fetching any resource that Apache is able to serve now, but restricting the response to a portion of it - while keeping those relative URLs working. With the "/~~/" syntax, XCAP has the flaw (a big flaw IMHO) that a generic XCAP module for restricting views cannot be written: such a module would have to know how to transform relative URLs appearing in the body, and that implies document-type-specific parsers. To whom do I write to be sure this issue is properly considered? -- Jamie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 09:43:33 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 JAA22947; Tue, 30 Nov 2004 09:43:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9JF-0005Cf-Tc; Tue, 30 Nov 2004 09:48:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zu-0008Sy-MQ; Tue, 30 Nov 2004 09:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX7Se-0001Jk-My for simple@megatron.ietf.org; Wed, 24 Nov 2004 19:26: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 TAA20311 for ; Wed, 24 Nov 2004 19:26:09 -0500 (EST) Received: from mail.shareable.org ([81.29.64.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7Wc-0002TI-Ko for simple@ietf.org; Wed, 24 Nov 2004 19:30:19 -0500 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id iAP0QB81006622; Thu, 25 Nov 2004 00:26:11 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id iAP0QBO7006620; Thu, 25 Nov 2004 00:26:11 GMT Date: Thu, 25 Nov 2004 00:26:11 +0000 From: Jamie Lokier To: Lisa Dusseault Message-ID: <20041125002611.GB5730@mail.shareable.org> References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <72CCFDEA-3E77-11D9-B57F-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72CCFDEA-3E77-11D9-B57F-000A95B2BB72@osafoundation.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Cc: Alex Rousskov , HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Lisa Dusseault wrote: > It's manageable from a coding point of view, I'm sure we're all > excellent coders. It's not manageable from an ease-of-use, application > design and GUI point of view, nor does it scale as far. I really can't > think how a GUI client/user can possibly manage all the ACLs on all the > node resources -- the complexity is enormous if it's not scoped down > somehow, and if it's not scoped down now, then the natural diversity of > implementations will make it much harder to scope down later. Imagine an XML document which is a web page. It seems quite reasonable to allow writing to selected portions of the page, but not to other portions or the page as a whole. That's a simple example of per-selector ACLs. There is no way a client-side GUI can handle that. ACLs of different selectors are related. In this case, a server might have logic which says a selected portion of a document is writable _if and only if_ it contains no read-only nodes. Changing permission of portions of the document would effectively modify the ACLs of other selectable portions - in ways which a generic client cannot know about. So the best a generic client GUI could do would be to try operations on a selected portion to discover if they are permitted, or query for the permitted operations on a portion before telling the user it's ok to start editing this portion. -- Jamie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 09:44:21 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 JAA23035; Tue, 30 Nov 2004 09:44:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9K0-0005Df-D2; Tue, 30 Nov 2004 09:49:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zw-00005Q-4y; Tue, 30 Nov 2004 09:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX7WM-0002Hq-3U for simple@megatron.ietf.org; Wed, 24 Nov 2004 19:30: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 TAA20589 for ; Wed, 24 Nov 2004 19:29:58 -0500 (EST) Received: from mail.shareable.org ([81.29.64.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7aK-0002YO-7L for simple@ietf.org; Wed, 24 Nov 2004 19:34:08 -0500 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id iAP0Sw81006674; Thu, 25 Nov 2004 00:28:58 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id iAP0SwZF006672; Thu, 25 Nov 2004 00:28:58 GMT Date: Thu, 25 Nov 2004 00:28:58 +0000 From: Jamie Lokier To: Lisa Dusseault Subject: Re: [Simple] Some thoughts on XCAP's resource architecture Message-ID: <20041125002858.GC5730@mail.shareable.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Cc: Cullen Jennings , HTTP working group , "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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. Maybe XCAP could take advantage of PATCH? :) -- Jamie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 09:45:36 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 JAA23207; Tue, 30 Nov 2004 09:45:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9LD-0005H3-Ek; Tue, 30 Nov 2004 09:50:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zw-00005W-OC; Tue, 30 Nov 2004 09:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEKB-0007wq-I9 for simple@megatron.ietf.org; Thu, 25 Nov 2004 02:45: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 CAA09531 for ; Thu, 25 Nov 2004 02:45:53 -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 1CXEOC-0003XO-N0 for simple@ietf.org; Thu, 25 Nov 2004 02:50:05 -0500 Received: (qmail 23337 invoked by uid 65534); 25 Nov 2004 07:45:18 -0000 Received: from pD95353FD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.83.253) by mail.gmx.net (mp011) with SMTP; 25 Nov 2004 08:45:18 +0100 X-Authenticated: #1915285 Message-ID: <41A58D8B.2070602@gmx.de> Date: Thu, 25 Nov 2004 08:45:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <72CCFDEA-3E77-11D9-B57F-000A95B2BB72@osafoundation.org> In-Reply-To: <72CCFDEA-3E77-11D9-B57F-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:33 -0500 Cc: Alex Rousskov , HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > ... > It's manageable from a coding point of view, I'm sure we're all > excellent coders. It's not manageable from an ease-of-use, application > design and GUI point of view, nor does it scale as far. I really can't > think how a GUI client/user can possibly manage all the ACLs on all the > node resources -- the complexity is enormous if it's not scoped down > somehow, and if it's not scoped down now, then the natural diversity of > implementations will make it much harder to scope down later. The difference is that in XCAP, you leave the decision about what granularity the ACLs will have to the server. It's perfectly ok if the server chooses to have just one for the whole document. But if it wishes to support a higher granularity, it can do that as well. Julian -- 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 Tue Nov 30 09:45: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 JAA23238; Tue, 30 Nov 2004 09:45:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Lb-0005HT-Hk; Tue, 30 Nov 2004 09:51:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zy-0000Dc-LM; Tue, 30 Nov 2004 09:28:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEy9-0000cl-6y for simple@megatron.ietf.org; Thu, 25 Nov 2004 03:27:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14107 for ; Thu, 25 Nov 2004 03:27:10 -0500 (EST) Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXF29-0004ex-HL for simple@ietf.org; Thu, 25 Nov 2004 03:31:22 -0500 Received: (qmail 21730 invoked by uid 65534); 25 Nov 2004 08:26:38 -0000 Received: from pD95353FD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.83.253) by mail.gmx.net (mp029) with SMTP; 25 Nov 2004 09:26:38 +0100 X-Authenticated: #1915285 Message-ID: <41A5973C.4050304@gmx.de> Date: Thu, 25 Nov 2004 09:26:36 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <41A508C1.8070900@gmx.de> <20041125002050.GA5730@mail.shareable.org> In-Reply-To: <20041125002050.GA5730@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:33 -0500 Cc: Lisa Dusseault , HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > ... > No, actually there is an important reason why XCAP should be changed > to be after the query part. > > Clearly, generic origin XCAP servers should not have to analyse and > transform the text of XML document - they should simply know how to > select portions of it based on the XCAP selector. > > With the "/~~/" syntax, think about what happens when an XCAP resource > is fetched by non-XCAP aware software that is given an XCAP URL. For > example, a web browser told to view a subtree of some XML document. > > That is one of the most useful reasons why XCAP is operating using > HTTP URLs, after all. I tend to disagree. a) That you can use a browser is a useful feature for debugging, but unlikely to be the primary way XCAP would be used, b) As long as each addressable fragment *does* get it's own URI, every solution will work equally well in a browser. > Relative URLs appearing in the text of the subtree will be resolved by > the browser including components of the selector. ...by any XML compliant recipient. Anyway, validaty of relative (URI) references is a problem, but a bigger one. Consider If you just address y, you'll loose the base URI information. So to make this work, an XCAP server would need to know about base URIs and xml:base anyway. > ... Best regards, Julian -- 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 Tue Nov 30 09:46:35 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 JAA23394; Tue, 30 Nov 2004 09:46:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9MB-0005JV-SL; Tue, 30 Nov 2004 09:51:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zz-0000FA-AC; Tue, 30 Nov 2004 09:28:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhWS-0006TI-UE for simple@megatron.ietf.org; Fri, 26 Nov 2004 09:56: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 EAA20518 for ; Fri, 26 Nov 2004 04:12:15 -0500 (EST) Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXcDY-0003RA-NK for simple@ietf.org; Fri, 26 Nov 2004 04:16:41 -0500 Received: (qmail 17990 invoked by uid 65534); 26 Nov 2004 09:11:44 -0000 Received: from pD9FF0BE0.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.11.224) by mail.gmx.net (mp014) with SMTP; 26 Nov 2004 10:11:44 +0100 X-Authenticated: #1915285 Message-ID: <41A6F34B.4090401@gmx.de> Date: Fri, 26 Nov 2004 10:11:39 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <41A508C1.8070900@gmx.de> <20041125002050.GA5730@mail.shareable.org> <41A5973C.4050304@gmx.de> <20041126075925.GB1385@mail.shareable.org> In-Reply-To: <20041126075925.GB1385@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:33 -0500 Cc: Lisa Dusseault , HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > ... >>...by any XML compliant recipient. Anyway, validaty of relative (URI) >>references is a problem, but a bigger one. Consider >> >> >> >>If you just address y, you'll loose the base URI information. So to make >>this work, an XCAP server would need to know about base URIs and >>xml:base anyway. > > > xml:base at the top-most tag is essentially document metadata. (I > don't know about xml:base - is it allowed to appear anywhere?) Yes. > Other things such as the charset in the declaration also need > to be passed. Any XCAP server will have a mechanism for extracting Not necessarily. A server could serve all fragments encoded in UTF-8 and would never have to send an XML declaration. Strictly speaking, it wouldn't need to send it as well if it's specified in the Content-Type response header. > and passing document metadata along with the response, and xml:base or > HTML's are just another part of that. > > My main point is that when an XML document contains relative URIs, > those are relative to the _document as a whole_. That's not true. The relative references need to get resolved to whatever the *current* base URI is. The base URI may change due to entity inclusion and xml:base processing. > It's a conceptual thing. > > The concept with XCAP is to address portions of an XML document. The > XML rules and general practice mean that relative URIs appearing in > those portions are still _supposed_ to be relative to the whole document. No, that's incorrect. > Therefore _conceptually_, the XCAP selectors should not change the > base path for relative URI resolution. Yes, but as demonstrated, that's fixable. > As it is now, an XCAP server would have to parse and modify the entire > selected portion to transform every relative URI, not just the single > base URI. No, that's incorrect. > (Alternatively it could add its own xml:base to the served response, > but that might not be so reliably understood by recipients.) > > This is because of the mismatch between the two concepts. That's what I already proposed (I think). Just clarify it in the spec, and there should be a problem with it. Best regards, Julian -- 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 Tue Nov 30 09:47: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 JAA23465; Tue, 30 Nov 2004 09:47:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Mk-0005Ku-Q1; Tue, 30 Nov 2004 09:52:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8zz-0000FG-Tg; Tue, 30 Nov 2004 09:28:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhoi-0007ga-FF for simple@megatron.ietf.org; Fri, 26 Nov 2004 10:15: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 CAA16689 for ; Fri, 26 Nov 2004 02:59:42 -0500 (EST) Received: from mail.shareable.org ([81.29.64.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXb5K-0001s7-4O for simple@ietf.org; Fri, 26 Nov 2004 03:04:06 -0500 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id iAQ7xP81001940; Fri, 26 Nov 2004 07:59:25 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id iAQ7xPY5001938; Fri, 26 Nov 2004 07:59:25 GMT Date: Fri, 26 Nov 2004 07:59:25 +0000 From: Jamie Lokier To: Julian Reschke Message-ID: <20041126075925.GB1385@mail.shareable.org> References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <41A508C1.8070900@gmx.de> <20041125002050.GA5730@mail.shareable.org> <41A5973C.4050304@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A5973C.4050304@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Cc: Lisa Dusseault , HTTP working group , "'simple@ietf.org'" Subject: [Simple] Re: Some thoughts on XCAP's resource architecture X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Julian Reschke wrote: > >is fetched by non-XCAP aware software that is given an XCAP URL. For > >example, a web browser told to view a subtree of some XML document. > > > >That is one of the most useful reasons why XCAP is operating using > >HTTP URLs, after all. > > I tend to disagree. > > a) That you can use a browser is a useful feature for debugging, but > unlikely to be the primary way XCAP would be used, > > b) As long as each addressable fragment *does* get it's own URI, every > solution will work equally well in a browser. I wasn't really thinking about normal web browsers, but rather clients which can fetch resources from XML URIs and do useful things with them, including following the URIs within the resources. I'm thinking that the selectors work rather like the Range header in some ways, but because they're in the URL it's reasonable to pass them around among different programs. For example, program A computes the selector for a certain kind of XCAP query, and passes it to program B which can retrieve the query result, which might contain references to other resources (or even other query results). > >Relative URLs appearing in the text of the subtree will be resolved by > >the browser including components of the selector. > > ...by any XML compliant recipient. Anyway, validaty of relative (URI) > references is a problem, but a bigger one. Consider > > > > If you just address y, you'll loose the base URI information. So to make > this work, an XCAP server would need to know about base URIs and > xml:base anyway. xml:base at the top-most tag is essentially document metadata. (I don't know about xml:base - is it allowed to appear anywhere?) Other things such as the charset in the declaration also need to be passed. Any XCAP server will have a mechanism for extracting and passing document metadata along with the response, and xml:base or HTML's are just another part of that. My main point is that when an XML document contains relative URIs, those are relative to the _document as a whole_. It's a conceptual thing. The concept with XCAP is to address portions of an XML document. The XML rules and general practice mean that relative URIs appearing in those portions are still _supposed_ to be relative to the whole document. Therefore _conceptually_, the XCAP selectors should not change the base path for relative URI resolution. As it is now, an XCAP server would have to parse and modify the entire selected portion to transform every relative URI, not just the single base URI. (Alternatively it could add its own xml:base to the served response, but that might not be so reliably understood by recipients.) This is because of the mismatch between the two concepts. If XML URIs normally refered to subtrees in the XML, there would be no mismatch, but they don't so there is. -- Jamie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 09:48: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 JAA23550; Tue, 30 Nov 2004 09:48:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Nf-0005MO-58; Tue, 30 Nov 2004 09:53:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ900-0000FL-EG; Tue, 30 Nov 2004 09:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYNK4-0002GQ-5M for simple@megatron.ietf.org; Sun, 28 Nov 2004 06:34:32 -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 GAA03084 for ; Sun, 28 Nov 2004 06:34:29 -0500 (EST) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYNOj-0003N3-Sv for simple@ietf.org; Sun, 28 Nov 2004 06:39:22 -0500 Received: (qmail 9233 invoked by uid 65534); 28 Nov 2004 11:33:57 -0000 Received: from pD9E512F9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.18.249) by mail.gmx.net (mp007) with SMTP; 28 Nov 2004 12:33:57 +0100 X-Authenticated: #1915285 Message-ID: <41A9B79A.9020904@gmx.de> Date: Sun, 28 Nov 2004 12:33:46 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: KAWAGUTI Ginga Subject: Re: [Simple] Some thoughts on XCAP's resource architecture References: <6E22F5F4-3C32-11D9-81D1-000A95B2BB72@osafoundation.org> <20041128012722.GA49273%ginga@ginganet.org> In-Reply-To: <20041128012722.GA49273%ginga@ginganet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:33 -0500 Cc: Lisa Dusseault , HTTP working group , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit 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). > 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? > (People who lives in us-ascii world, or even iso-8859-* world, > might not realize what these problems are...) Oh yes, I do :-) Best regards, Julian -- 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 Tue Nov 30 09:48:21 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 JAA23582; Tue, 30 Nov 2004 09:48:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Nt-0005N3-20; Tue, 30 Nov 2004 09:53:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ900-0000FR-Us; Tue, 30 Nov 2004 09:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkeL-0008Sg-82 for simple@megatron.ietf.org; Mon, 29 Nov 2004 07:29: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 EAA28385 for ; Mon, 29 Nov 2004 04:01:14 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYhU9-0003XJ-BK for simple@ietf.org; Mon, 29 Nov 2004 04:06:18 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61554 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CYhOk-0005KB-Tj; Mon, 29 Nov 2004 09:00:43 +0000 In-Reply-To: <41AAE435.3020503@nokia.com> References: <41937A34.6060002@nokia.com> <968E85DE-3FF4-11D9-8B4D-000D93B0AE1A@nostrum.com> <41AAE435.3020503@nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2124E9F4-41E5-11D9-8863-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Mon, 29 Nov 2004 09:00:34 +0000 To: Miguel Garcia X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Nov 2004 09:28:34 -0500 Cc: Simple WG Subject: [Simple] Re: Comments on IANA registration at MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit On 29 Nov 2004, at 08:56, Miguel Garcia wrote: > Probably it makes more sense that sdp-new registers the top-level > "message" MIME type. > > Colin, since you are editing SDP-new, can you add the "message" > registry to the next version? It's in -sdp-new-22, which I submitted a couple of days ago. Colin _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 30 13:14: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 NAA15957; Tue, 30 Nov 2004 13:14:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCb3-0002ct-69; Tue, 30 Nov 2004 13:19:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCEZ-0005cr-OG; Tue, 30 Nov 2004 12:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCAJ-0004Dx-II for simple@megatron.ietf.org; Tue, 30 Nov 2004 12:51: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 MAA13388 for ; Tue, 30 Nov 2004 12:51:48 -0500 (EST) Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCFL-0001w8-NO for simple@ietf.org; Tue, 30 Nov 2004 12:57:11 -0500 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0I8000CQ16XCVX@firewall.mci.com> for simple@ietf.org; Tue, 30 Nov 2004 17:51:12 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I80001016XA4W@dgismtp05.mcilink.com> for simple@ietf.org; Tue, 30 Nov 2004 17:51:12 +0000 (GMT) Received: from dgmexch09.wcomnet.com ([166.38.58.240]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I8000MLL6XBV0@dgismtp05.mcilink.com> for simple@ietf.org; Tue, 30 Nov 2004 17:51:11 +0000 (GMT) Received: by DGMEXCH09.mcilink.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Nov 2004 17:58:01 +0000 Content-return: allowed Date: Tue, 30 Nov 2004 17:51:04 +0000 From: "Johnston, Alan" To: "'simple@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; CHARSET=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Simple] FW: XCON Interim Attendance Poll - please respond X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d FYI -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Johnston, Alan Sent: Tuesday, November 23, 2004 2:21 PM To: xcon@ietf.org Cc: 'Adam@nostrum.com' Subject: [XCON] XCON Interim Attendance Poll - please respond All, The XCON working group interim meeting is being planned for January 5 and January 6, 2005 in Boston, MA. The exact location and agenda with hotel information will be posted in about a week, as will the official announcement on the IETF Announce list. For the moment, if you plan to attend, or know of people in your organization who plan to attend, please send an email directly to me (mailto:alan.johnston@mci.com) (do *not* send to the list) so we can get an accurate count to finalize the planning. Please respond in the next week, by November 30. Thanks, Alan Johnston co-chair XCON _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple