"Bernard Aboba" <bernar= d=5Faboba@hotmail.com> · 02/12/2009 01:16 AM

The following is a plan for =
revising the draft
to address these comments.
The plan is based on discussions =
with Ben,
Cullen and Robert.
One very important thing that will =
help us a
lot in this work is getting
real data from actual deployments =
of SIMPLE
regarding the following:
- Message sizes.
- Different refresh (re-subscribe) =
rates
used and when they are used.
- Presence document data =
sizes
- Geolocation presence document =
data sizes.
- Size of data per subscription =
that the
presence server needs to
  allocate
- Any other data that we can get =
from the
field.
**** Any numbers here will be =
greatly
appreciated and will help a lot
in creating the new revision of the =
document
****
Note that the above numbers are =
more SIP
specific and we need to get  
them from actual SIP deployments. They are different from the =

general constants of buddy list size, rate of state changes per day =
etc.
which are more usage =
numbers.
General Changes:
----------------
* Remove subjective language as =
much as
possible
* The document should not be written as a protocol comparison =
document
but as a document that provides =
input that
will help deployment  
considerations for SIMPLE and directions for optimizations.
* Clarify the assumptions behind =
the chosen
input values.
* Discuss elasticity of inputs and =
which
inputs have more effect.
* Make it clear that we are talking only about inter-domain =

traffic.
* The document will have to go =
through the
working group last call  
again.
Changes in Phase I
-------------------
* Separate the scenarios into =
enterprise and
consumer related  
scenarios. Number as the time that a user will be logged in which =
is
reasonable to be 8 in an enterprise =
will be
different for a consumer
network. The rate of status changes =
will be
different also.
* Since we can not mention explicit =
numbers
from actual deployments,  
we should say e.g. "hypothetical consumer =
service"...
* Add per active (logged in) user calculations
* Section 2.2: The 2000/4000 =
difference in
login/logouts is probably  
a typo mistake that needs to be clarified. It does NOT affect the =

calculations.
* Add a section describing changes =
with
different constants. Provide  
several points on the possible reasonable values.
* Add geolocation information as =
part of the
model.
* Provide different calculations for the refresh time. The 3600 =

seconds from the RFC is not the number that is usually =
used.
Provide both =
extremes.
* Message sizes: Need to do sanity check of messages. Talk to people =

that may have these numbers.
* Section 2.10 - Change to 48 changes per day from 24. It was done =

in order to show that the optimized protocol can be better even =
with
doubling the number notifications. =
This is
probably confusing and need to
be fixed.
* Sizes for state calculations. =
Need to
revisit the numbers that are  
used. Get actual numbers from the same sources that we will get =
message
sizes.
* Talk about the limits that are =
imposed by
privacy constraints on  
the way that SIMPLE works and possible optimizations.
* Provide numbers for when SIGCOMP
compression is used.
Phase II
--------
* Revisit Processing Complexities, =
Current
Optimizations, Summary and
Conclusions sections after doing the changes in the main part of the =

document.
Thanks
--Avshalom”
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

Simple mailing list

Simple@ietf.org

https://www.ietf.org/mailman/listinfo/simple
=

simple-bounces@ietf.org wrote on 08/12/2009 08:47:55
PM:

> From:
> 

> Peter Saint-Andre <stpeter@stpeter.im>
> 

> To:
> 

> Bernard Aboba <bernard=5Faboba@hotmail.com>
> 

> Cc:
> 

> simple@ietf.org
> 

> Date:
> 

> 08/12/2009 08:48 PM
> 

> Subject:
> 

> Re: [Simple] Suggested next actions with draft-ietf-simple-

> interdomain-scaling-analysis
> 

> Sent by:
> 

> simple-bounces@ietf.org
> 

> If we work on a more general analysis, perhaps there might not be
next

> steps on draft-ietf-simple-interdomain-scaling-analysis. I think it's<=
br>
> too early to say.

> 

> On 12/8/09 11:44 AM, Bernard Aboba wrote:

> > I agree with all of Peter’s points below.

> > 

> >  

> > 

> > However, this begs the question of what the next steps are on

> > 

> > draft-ietf-simple-interdomain-scaling-analysis.

> > 

> >  

> > 

> > IMHO, both draft-ietf-simple-interdomain-scaling-analysis and

> > 

> > draft-saintandre-xmpp-presence-analysis would benefit from the
context that

> > 

> > Peter’s suggested “more general analysis” would=
 provide. 

> > 

> >  

> > 

> > Not only would that context make both documents more understandab=
le,
but

> > 

> > it would also help answer the questions posed in item #5.  
“Better

> > numbers” by

> > 

> > themselves can’t accomplish that.

> > 

> >  

> > 

> >  

> > 

> >  

> > 

> > Peter Saint-Andre wrote:

> > 

> >> Avshalom and I just had a chat about this I-D. He might post
in more

> > 

> >> detail, but my main conclusions are as follows:

> > 

> >>

> > 

> >> 1. Analyzing the network impact of presence technologies
is the

> > 

> >> responsible thing for the IETF to do.

> > 

> >>

> > 

> >> 2. The analyses in draft-ietf-simple-interdomain-scaling-anal=
ysis
and

> > 

> >> draft-saintandre-xmpp-presence-analysis are not intended
to force work

> > 

> >> on optimizations, instead they are intended to frame a broade=
r

> > 

> >> discussion about the network impact of presence technologies.=

> > 

> >>

> > 

> >> 3. It's unproductive to set up a competition in this regard
between

> > 

> >> SIP and XMPP.

> > 

> >>

> > 

> >> 4. It would be more productive to move up a level of abstract=
ion
by

> > 

> >> discussing presence technologies at a higher level (not speci=
fic
to

> > 

> >> SIP or XMPP).

> > 

> >>

> > 

> >> 5. A more general treatment might help protocol designers,
application

> > 

> >> developers, and service operators think more clearly about
protocol

> > 

> >> optimizations, implementation improvements, and deployment
sizing.

> > 

> >> However, detailed discussion of those issues belongs somewhere
else,

> > 

> >> not in the general analysis document.

> > 

> >>

> > 

> >> If people on this list think it would be helpful, Avshalom
and I are

> > 

> >> open to working together on a more general analysis.

> > 

> >>

> > 

> >> Peter

> 

> [attachment "smime.p7s" deleted by Avshalom Houri/Haifa/IBM]

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

> Simple mailing list

> Simple@ietf.org

> 

simple-bounces@ietf.org =
wrote on 08/12/2009 08:47:55
PM:

> From:
> 

> Peter Saint-Andre <stpeter@stpeter.im>
> 

> To:
> 

> Bernard Aboba <bernard_aboba@hotmail.com>=
;
> 

> Cc:
> 

> simple@ietf.org
> 

> Date:
> 

> 08/12/2009 08:48 PM
> 

> Subject:
> 

> Re: [Simple] Suggested next actions with draft-ietf-simple-

> interdomain-scaling-analysis
> 

> Sent by:
> 

> simple-bounces@ietf.org=

> 

> If we work on a more general analysis, perhaps there might not be
next

> steps on draft-ietf-simple-interdomain-scaling-analysis. I think =
it's

> too early to say.

> 

> On 12/8/09 11:44 AM, Bernard Aboba wrote:

> > I agree with all of Peter=92s points below.

> > 

> >  

> > 

> > However, this begs the question of what the next steps are =
on

> > 

> > draft-ietf-simple-interdomain-scaling-analysis.

> > 

> >  

> > 

> > IMHO, both draft-ietf-simple-interdomain-scaling-analysis =
and

> > 

> > draft-saintandre-xmpp-presence-analysis would benefit from the
context that

> > 

> > Peter=92s suggested =93more general analysis=94 would provide. =

> > 

> >  

> > 

> > Not only would that context make both documents more =
understandable,
but

> > 

> > it would also help answer the questions posed in item #5. =

=93Better

> > numbers=94 by

> > 

> > themselves can=92t accomplish that.

> > 

> >  

> > 

> >  

> > 

> >  

> > 

> > Peter Saint-Andre wrote:

> > 

> >> Avshalom and I just had a chat about this I-D. He might =
post
in more

> > 

> >> detail, but my main conclusions are as follows:

> > 

> >>

> > 

> >> 1. Analyzing the network impact of presence technologies
is the

> > 

> >> responsible thing for the IETF to do.

> > 

> >>

> > 

> >> 2. The analyses in =
draft-ietf-simple-interdomain-scaling-analysis
and

> > 

> >> draft-saintandre-xmpp-presence-analysis are not intended
to force work

> > 

> >> on optimizations, instead they are intended to frame a =
broader

> > 

> >> discussion about the network impact of presence =
technologies.

> > 

> >>

> > 

> >> 3. It's unproductive to set up a competition in this =
regard
between

> > 

> >> SIP and XMPP.

> > 

> >>

> > 

> >> 4. It would be more productive to move up a level of =
abstraction
by

> > 

> >> discussing presence technologies at a higher level (not =
specific
to

> > 

> >> SIP or XMPP).

> > 

> >>

> > 

> >> 5. A more general treatment might help protocol designers,
application

> > 

> >> developers, and service operators think more clearly about
protocol

> > 

> >> optimizations, implementation improvements, and deployment
sizing.

> > 

> >> However, detailed discussion of those issues belongs =
somewhere
else,

> > 

> >> not in the general analysis document.

> > 

> >>

> > 

> >> If people on this list think it would be helpful, Avshalom
and I are

> > 

> >> open to working together on a more general analysis.

> > 

> >>

> > 

> >> Peter

> 

> [attachment "smime.p7s" deleted by Avshalom Houri/Haifa/IBM]

> _______________________________________________

> Simple mailing list

> Simple@ietf.org

> 
https://www.ietf.org/mailman/listinfo/simple
simple-bounces@ietf.org wrote on 08/12/2009 08:47:55
PM:

> From:
> 

> Peter Saint-Andre <stpeter@stpeter.im>
> 

> To:
> 

> Bernard Aboba <bernard_aboba@hotmail.com>
> 

> Cc:
> 

> simple@ietf.org
> 

> Date:
> 

> 08/12/2009 08:48 PM
> 

> Subject:
> 

> Re: [Simple] Suggested next actions with draft-ietf-simple-

> interdomain-scaling-analysis
> 

> Sent by:
> 

> 
simple-bo=
unces@ietf.org
> 

> If we work on a more general analysis, perhaps there might not be
next

> steps on draft-ietf-simple-interdomain-scaling-analysis. I think it=
9;s

> too early to say.

> 

> On 12/8/09 11:44 AM, Bernard Aboba wrote:

> > I agree with all of Peter=92s points below.

> > 

> > =A0

> > 

> > However, this begs the question of what the next steps are on

> > 

> > draft-ietf-simple-interdomain-scaling-analysis.

> > 

> > =A0

> > 

> > IMHO, both draft-ietf-simple-interdomain-scaling-analysis and

> > 

> > draft-saintandre-xmpp-presence-analysis would benefit from the
context that

> > 

> > Peter=92s suggested =93more general analysis=94 would provide. 
> > 

> > =A0

> > 

> > Not only would that context make both documents more understandab=
le,
but

> > 

> > it would also help answer the questions posed in item #5. =A0
=93Better

> > numbers=94 by

> > 

> > themselves can=92t accomplish that.

> > 

> > =A0

> > 

> > =A0

> > 

> > =A0

> > 

> > Peter Saint-Andre wrote:

> > 

> >> Avshalom and I just had a chat about this I-D. He might post
in more

> > 

> >> detail, but my main conclusions are as follows:

> > 

> >>

> > 

> >> 1. Analyzing the network impact of presence technologies
is the

> > 

> >> responsible thing for the IETF to do.

> > 

> >>

> > 

> >> 2. The analyses in draft-ietf-simple-interdomain-scaling-anal=
ysis
and

> > 

> >> draft-saintandre-xmpp-presence-analysis are not intended
to force work

> > 

> >> on optimizations, instead they are intended to frame a broade=
r

> > 

> >> discussion about the network impact of presence technologies.=

> > 

> >>

> > 

> >> 3. It's unproductive to set up a competition in this rega=
rd
between

> > 

> >> SIP and XMPP.

> > 

> >>

> > 

> >> 4. It would be more productive to move up a level of abstract=
ion
by

> > 

> >> discussing presence technologies at a higher level (not speci=
fic
to

> > 

> >> SIP or XMPP).

> > 

> >>

> > 

> >> 5. A more general treatment might help protocol designers,
application

> > 

> >> developers, and service operators think more clearly about
protocol

> > 

> >> optimizations, implementation improvements, and deployment
sizing.

> > 

> >> However, detailed discussion of those issues belongs somewher=
e
else,

> > 

> >> not in the general analysis document.

> > 

> >>

> > 

> >> If people on this list think it would be helpful, Avshalom
and I are

> > 

> >> open to working together on a more general analysis.

> > 

> >>

> > 

> >> Peter

> 

> [attachment "smime.p7s" deleted by Avshalom Houri/Haifa/IBM]

> _______________________________________________

> Simple mailing list

> Simple@ietf.org

> 
https://www.ietf.org/mailman/li=
stinfo/simple

simple-bounces@ietf.org

wrote on 08/12/2009 08:47:55 PM:

> From: 

> 

> Peter Saint-Andre <stpeter@stpeter.im=
>

> 

> To: 

> 

> Bernard Aboba <bernard=5Faboba@h=
otmail.com>

> 

> Cc: 

> 

> simple@ietf.org

> 

> Date: 

> 

> 08/12/2009 08:48 PM 

> 

> Subject: 

> 

> Re: [Simple] Suggested next actions with draft-ietf-simple-

> interdomain-scaling-analysis 

> 

> Sent by:

> 

> simple-bounces@ietf.org

> 

> If we work on a more general analysis, perhaps
there might not be next

> steps on draft-ietf-simple-interdomain-scaling-analysis. I think it's<=
br>
> too early to say.

> 

> On 12/8/09 11:44 AM, Bernard Aboba wrote:

> > I agree with all of Peter’s points below.

> > 

> >  

> > 

> > However, this begs the question of what the next steps are on

> > 

> > draft-ietf-simple-interdomain-scaling-analysis.

> > 

> >  

> > 

> > IMHO, both draft-ietf-simple-interdomain-scaling-analysis and

> > 

> > draft-saintandre-xmpp-presence-analysis would benefit from the
context that

> > 

> > Peter’s suggested “more general analysis” would=
 provide. 

> > 

> >  

> > 

> > Not only would that context make both documents more understandab=
le,
but

> > 

> > it would also help answer the questions posed in item #5.  
“Better

> > numbers” by

> > 

> > themselves can’t accomplish that.

> > 

> >  

> > 

> >  

> > 

> >  

> > 

> > Peter Saint-Andre wrote:

> > 

> >> Avshalom and I just had a chat about this I-D. He might post
in more

> > 

> >> detail, but my main conclusions are as follows:

> > 

> >>

> > 

> >> 1. Analyzing the network impact of presence technologies
is the

> > 

> >> responsible thing for the IETF to do.

> > 

> >>

> > 

> >> 2. The analyses in draft-ietf-simple-interdomain-scaling-anal=
ysis
and

> > 

> >> draft-saintandre-xmpp-presence-analysis are not intended
to force work

> > 

> >> on optimizations, instead they are intended to frame a broade=
r

> > 

> >> discussion about the network impact of presence technologies.=

> > 

> >>

> > 

> >> 3. It's unproductive to set up a competition in this regard
between

> > 

> >> SIP and XMPP.

> > 

> >>

> > 

> >> 4. It would be more productive to move up a level of abstract=
ion
by

> > 

> >> discussing presence technologies at a higher level (not speci=
fic
to

> > 

> >> SIP or XMPP).

> > 

> >>

> > 

> >> 5. A more general treatment might help protocol designers,
application

> > 

> >> developers, and service operators think more clearly about
protocol

> > 

> >> optimizations, implementation improvements, and deployment
sizing.

> > 

> >> However, detailed discussion of those issues belongs somewhere
else,

> > 

> >> not in the general analysis document.

> > 

> >>

> > 

> >> If people on this list think it would be helpful, Avshalom
and I are

> > 

> >> open to working together on a more general analysis.

> > 

> >>

> > 

> >> Peter

> 

> [attachment "smime.p7s" deleted by
Avshalom Houri/Haifa/IBM] 

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F

> Simple mailing list

> Simple@ietf.org

> 

https://www.ietf.org/mailman/listinfo/=
simple

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

Simple mailing list

=
Simple@ietf.org

https://www.ietf.org/mailman/listin=
fo/simple

--=_alternative 0039DA8CC225768E_=--

From AVSHALOM@il.ibm.com  Wed Dec 16 02:40:44 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F51C3A6B49 for ; Wed, 16 Dec 2009 02:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.745
X-Spam-Level: 
X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu9A+SbWeF6B for ; Wed, 16 Dec 2009 02:40:38 -0800 (PST)
Received: from mtagate6.de.ibm.com (mtagate6.de.ibm.com [195.212.17.166]) by core3.amsl.com (Postfix) with ESMTP id 868FE3A6941 for ; Wed, 16 Dec 2009 02:40:37 -0800 (PST)
Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate6.de.ibm.com (8.13.1/8.13.1) with ESMTP id nBGAeM3X019372 for ; Wed, 16 Dec 2009 10:40:22 GMT
Received: from d12av06.megacenter.de.ibm.com (d12av06.megacenter.de.ibm.com [9.149.165.230]) by d12nrmr1507.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBGAeM8j2609368 for ; Wed, 16 Dec 2009 11:40:22 +0100
Received: from d12av06.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av06.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBGAeMDP031938 for ; Wed, 16 Dec 2009 11:40:22 +0100
Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av06.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBGAeMjk031935; Wed, 16 Dec 2009 11:40:22 +0100
In-Reply-To: 
References:  <4B1E9F5B.9090109@stpeter.im>  
To: Ben Campbell 
MIME-Version: 1.0
X-KeepSent: AAAEA776:3655757F-C225768E:0039F3D0; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009
From: Avshalom Houri 
Message-ID: 
Date: Wed, 16 Dec 2009 12:40:20 +0200
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 16/12/2009 12:40:21, Serialize complete at 16/12/2009 12:40:21
Content-Type: multipart/alternative; boundary="=_alternative 003A9E9DC225768E_="
Cc: simple@ietf.org
Subject: Re: [Simple] Suggested next	actions	with	draft-ietf-simple-interdomain-scaling-analysis
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2009 10:40:44 -0000

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

Ben,

I am not sure if there is an example of a similar document at the IETF.
The idea is as described by Peter in points 3 and 4 below is to discuss=20
presence scalability in
general and try to delay as much as possible (maybe appendixes)=20
discussions on specific protocols.

Anyway, I am not sure if there is enough support for more general document =

in the SIMPLE group
and not sure about if there is still interest in the original document in=20
the SIMPLE WG as the amount of
responses is scanty and we do not get any numbers from real deployments.=20
Are not there any deployments
of SIMPLE?

I am very frustrated regarding getting these type of comments from the=20
IESG on the last second before it was to
be approved as an RFC. However, I want to finish this document only more=20
as honor to the amount of work that
people have invested in this document.

So I should assume that there is not enough support for general document=20
in the SIMPLE group and I should porceed
with the original plan as was agreed also by Cullen?

Thanks
--Avshalom

From:
Ben Campbell 
To:
Avshalom Houri/Haifa/IBM@IBMIL
Cc:
simple@ietf.org, Peter Saint-Andre 
Date:
11/12/2009 12:35 AM
Subject:
Re: [Simple] Suggested next     actions with=20
draft-ietf-simple-interdomain-scaling-analysis

Hi Avshalom and Peter,

Can you offer some examples of the sort of analyses you have in mind?

On Dec 8, 2009, at 2:43 PM, Avshalom Houri wrote:

In other words, does the SIMPLE WG is interested in revising the the=20
interdomain-scaling draft to satisfy the last minute comments at the IESG=20
according to the work plan that I have sent to the list few weeks ago,=20
or they would rather prefer that Peter and me will work on a new a=20
document=20
that will merge both the SIMPLE and the XMPP scaling analysis documents=20
in a more general way as described in Peter's note below?=20

--Avshalom

simple-bounces@ietf.org wrote on 08/12/2009 08:47:55 PM:

> From:=20
>=20
> Peter Saint-Andre =20
>=20
> To:=20
>=20
> Bernard Aboba =20
>=20
> Cc:=20
>=20
> simple@ietf.org=20
>=20
> Date:=20
>=20
> 08/12/2009 08:48 PM=20
>=20
> Subject:=20
>=20
> Re: [Simple] Suggested next actions with draft-ietf-simple-
> interdomain-scaling-analysis=20
>=20
> Sent by:=20
>=20
> simple-bounces@ietf.org=20
>=20
> If we work on a more general analysis, perhaps there might not be next
> steps on draft-ietf-simple-interdomain-scaling-analysis. I think it's
> too early to say.
>=20
> On 12/8/09 11:44 AM, Bernard Aboba wrote:
> > I agree with all of Peter?s points below.
> >=20
> >=20
> >=20
> > However, this begs the question of what the next steps are on
> >=20
> > draft-ietf-simple-interdomain-scaling-analysis.
> >=20
> >=20
> >=20
> > IMHO, both draft-ietf-simple-interdomain-scaling-analysis and
> >=20
> > draft-saintandre-xmpp-presence-analysis would benefit from the context =

that
> >=20
> > Peter?s suggested ?more general analysis? would provide.=20
> >=20
> >=20
> >=20
> > Not only would that context make both documents more understandable,=20
but
> >=20
> > it would also help answer the questions posed in item #5.   ?Better
> > numbers? by
> >=20
> > themselves can?t accomplish that.
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > Peter Saint-Andre wrote:
> >=20
> >> Avshalom and I just had a chat about this I-D. He might post in more
> >=20
> >> detail, but my main conclusions are as follows:
> >=20
> >>
> >=20
> >> 1. Analyzing the network impact of presence technologies is the
> >=20
> >> responsible thing for the IETF to do.
> >=20
> >>
> >=20
> >> 2. The analyses in draft-ietf-simple-interdomain-scaling-analysis and
> >=20
> >> draft-saintandre-xmpp-presence-analysis are not intended to force=20
work
> >=20
> >> on optimizations, instead they are intended to frame a broader
> >=20
> >> discussion about the network impact of presence technologies.
> >=20
> >>
> >=20
> >> 3. It's unproductive to set up a competition in this regard between
> >=20
> >> SIP and XMPP.
> >=20
> >>
> >=20
> >> 4. It would be more productive to move up a level of abstraction by
> >=20
> >> discussing presence technologies at a higher level (not specific to
> >=20
> >> SIP or XMPP).
> >=20
> >>
> >=20
> >> 5. A more general treatment might help protocol designers,=20
application
> >=20
> >> developers, and service operators think more clearly about protocol
> >=20
> >> optimizations, implementation improvements, and deployment sizing.
> >=20
> >> However, detailed discussion of those issues belongs somewhere else,
> >=20
> >> not in the general analysis document.
> >=20
> >>
> >=20
> >> If people on this list think it would be helpful, Avshalom and I are
> >=20
> >> open to working together on a more general analysis.
> >=20
> >>
> >=20
> >> Peter
>=20
> [attachment "smime.p7s" deleted by Avshalom Houri/Haifa/IBM]=20
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

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

Ben,

I am not sure if there is an example
of a similar document at the IETF.

The idea is as described by Peter in
points 3 and 4 below is to discuss presence scalability in

general and try to delay as much as
possible (maybe appendixes) discussions on specific protocols.

Anyway, I am not sure if there is en=
ough
support for more general document in the SIMPLE group

and not sure about if there is still
interest in the original document in the SIMPLE WG as the amount of

responses is scanty and we do not get
any numbers from real deployments. Are not there any deployments

of SIMPLE?

I am very frustrated regarding getti=
ng
these type of comments from the IESG on the last second before it was to

be approved as an RFC. However, I wa=
nt
to finish this document only more as honor to the amount of work that

people have invested in this documen=
t.

So I should assume that there is not
enough support for general document in the SIMPLE group and I should porcee=
d

with the original plan as was agreed
also by Cullen?

Thanks

--Avshalom

From:
Ben Campbell <ben@estacado.net>=
;

To:
Avshalom Houri/Haifa/IBM@IBMIL

Cc:
simple@ietf.org, Peter Saint-Andre &=
lt;stpeter@stpeter.im>

Date:
11/12/2009 12:35 AM

Subject:
Re: [Simple] Suggested next   &=
nbsp;
   actions        with  
     draft-ietf-simple-interdomain-scaling-analysis

Hi Avshalom and Peter,

Can you offer some examples of the sort of analyses you
have in mind?

On Dec 8, 2009, at 2:43 PM, Avshalom Houri wrote:

In other words, does the SIMPLE WG
is interested in revising the the 

interdomain-scaling draft to satisfy the last minute comments at the IESG

according to the work plan that I have sent to the list few weeks ago,

or they would rather prefer that Peter and me will work on a new a document=

that will merge both the SIMPLE and the XMPP scaling analysis documents

in a more general way as described in Peter's note below?

--Avshalom

simple-bounces@ietf.org
wrote on 08/12/2009 08:47:55 PM:

> From: 

> 

> Peter Saint-Andre <=
stpeter@stpeter.im>

> 

> To: 

> 

> Bernard Aboba <bernard=5Faboba@hotmail.com>

> 

> Cc: 

> 

> simple@ietf.org

> 

> Date: 

> 

> 08/12/2009 08:48 PM 

> 

> Subject: 

> 

> Re: [Simple] Suggested next actions with draft-ietf-simple-

> interdomain-scaling-analysis 

> 

> Sent by: 

> 

> simple-bounces@ietf.org

> 

> If we work on a more general analysis, perhaps there might not be
next

> steps on draft-ietf-simple-interdomain-scaling-analysis. I think it's<=
br>
> too early to say.

> 

> On 12/8/09 11:44 AM, Bernard Aboba wrote:

> > I agree with all of Peter’s points below.

> > 

> >  

> > 

> > However, this begs the question of what the next steps are on

> > 

> > draft-ietf-simple-interdomain-scaling-analysis.

> > 

> >  

> > 

> > IMHO, both draft-ietf-simple-interdomain-scaling-analysis and

> > 

> > draft-saintandre-xmpp-presence-analysis would benefit from the
context that

> > 

> > Peter’s suggested “more general analysis” would=
 provide. 

> > 

> >  

> > 

> > Not only would that context make both documents more understandab=
le,
but

> > 

> > it would also help answer the questions posed in item #5.  
“Better

> > numbers” by

> > 

> > themselves can’t accomplish that.

> > 

> >  

> > 

> >  

> > 

> >  

> > 

> > Peter Saint-Andre wrote:

> > 

> >> Avshalom and I just had a chat about this I-D. He might post
in more

> > 

> >> detail, but my main conclusions are as follows:

> > 

> >>

> > 

> >> 1. Analyzing the network impact of presence technologies
is the

> > 

> >> responsible thing for the IETF to do.

> > 

> >>

> > 

> >> 2. The analyses in draft-ietf-simple-interdomain-scaling-anal=
ysis
and

> > 

> >> draft-saintandre-xmpp-presence-analysis are not intended
to force work

> > 

> >> on optimizations, instead they are intended to frame a broade=
r

> > 

> >> discussion about the network impact of presence technologies.=

> > 

> >>

> > 

> >> 3. It's unproductive to set up a competition in this regard
between

> > 

> >> SIP and XMPP.

> > 

> >>

> > 

> >> 4. It would be more productive to move up a level of abstract=
ion
by

> > 

> >> discussing presence technologies at a higher level (not speci=
fic
to

> > 

> >> SIP or XMPP).

> > 

> >>

> > 

> >> 5. A more general treatment might help protocol designers,
application

> > 

> >> developers, and service operators think more clearly about
protocol

> > 

> >> optimizations, implementation improvements, and deployment
sizing.

> > 

> >> However, detailed discussion of those issues belongs somewhere
else,

> > 

> >> not in the general analysis document.

> > 

> >>

> > 

> >> If people on this list think it would be helpful, Avshalom
and I are

> > 

> >> open to working together on a more general analysis.

> > 

> >>

> > 

> >> Peter

> 

> [attachment "smime.p7s" deleted by Avshalom Houri/Haifa/IBM]

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

> Simple mailing list

> Simple@ietf.org

> https://www.ietf.org/mailman/listinfo/simpl=
e

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

Simple mailing list

=
Simple@ietf.org

https://www.ietf.org/mailman/listinfo/simple

--=_alternative 003A9E9DC225768E_=--

From b_mccolgan@hotmail.com  Wed Dec 16 08:04:05 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D273A6890 for ; Wed, 16 Dec 2009 08:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.276
X-Spam-Level: 
X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxdGrHs6bUxX for ; Wed, 16 Dec 2009 08:04:04 -0800 (PST)
Received: from snt0-omc2-s36.snt0.hotmail.com (snt0-omc2-s36.snt0.hotmail.com [65.55.90.111]) by core3.amsl.com (Postfix) with ESMTP id 436793A6825 for ; Wed, 16 Dec 2009 08:04:04 -0800 (PST)
Received: from SNT114-W53 ([65.55.90.71]) by snt0-omc2-s36.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 16 Dec 2009 08:03:50 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_446f08ac-7aa8-4acd-8263-dceef42b3593_"
X-Originating-IP: [208.65.73.202]
From: Brian McColgan 
To: , 
Date: Wed, 16 Dec 2009 11:03:50 -0500
Importance: Normal
In-Reply-To: <2F8CCCCE-0CAA-4401-B0CF-25585C930D54@estacado.net>
References: , <2F8CCCCE-0CAA-4401-B0CF-25585C930D54@estacado.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Dec 2009 16:03:50.0676 (UTC) FILETIME=[5B96DD40:01CA7E69]
Subject: Re: [Simple] Closure on OMA Liaison Statement (was: Liaison Statement	from the Open Mobile Alliance)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2009 16:04:05 -0000

--_446f08ac-7aa8-4acd-8263-dceef42b3593_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

Hi Ben=2C

=20

I do not have an issue 'closing out' the liason statement on behalf of OMA=
=2C however IETF still has a problem 'in the large' with respect to identif=
ying the location of XML Schema's to potential implementors.

=20

IETF requires some mechanism (whether it be an ammendment to the RFC draft =
template) or the supplementary XML Schema template files to provide some in=
dicator of where 'soft copies' of XML Schema's can be found.

=20

To keep the XML guru's from jumping all over this proposal=2C let me be cle=
ar that I am NOT proposing the use of XML Schema syntax to achieve this.  A=
n informative comment=2C or addition to the RFC draft template (as previous=
ly noted) to me would fit the bill perfectly.  Even a boilerplate statement=
 saying (XML Schema's for RFCs may be found in the IANA XML Registry locate=
d here -  http://www.iana.org/assignments/xml-registry/schema.html) would b=
e helpful!

=20

As a good 'litmus test' poll a few of your 'implementor buddies' and ask th=
em whether they 'realize' or 'are aware' that XML Schema for RFCs actually =
exist on IANA.  I would bet money=2C most will have 'no clue' that RFC XML =
Schema's exist on IANA's web-site. =20

=20

I am happy to help in the effort=2C however I would like for IETF to not lo=
se momentum on a fix=2C while this subject is still 'fresh' in everyone's c=
ollective minds.

=20

Thanks for permitting me to provide comment.

=20

Cheers=2C

Brian

.
=20
> From: ben@estacado.net
> Date: Thu=2C 10 Dec 2009 15:45:40 -0600
> To: simple@ietf.org
> Subject: [Simple] Closure on OMA Liaison Statement (was: Liaison Statemen=
t from the Open Mobile Alliance)
>=20
> 
>=20
> From the list discussion so far=2C I draw the following conclusions:
>=20
> 1) We have consensus to ask IANA to update the published schemas to match=
 the definitions in RFC 4826.
>=20
> 2) Several people objected to adding the schemaLocation attribute. Theref=
ore=2C we do not have consensus to make this change.
>=20
> We will draw up a response to the liaison statement very soon=2C so if yo=
u disagree with the above conclusions=2C please make that known ASAP.
>=20
> Thanks!
>=20
> Ben.
>=20
> On Oct 2=2C 2009=2C at 1:12 PM=2C Ben Campbell wrote:
>=20
> > (as SIMPLE co-chair)
> >=20
> > OMA sent a liaison statement to the SIMPLE working group. The statement=
's overview reads as follows:
> >=20
> > "This Liaison Statement reports XML validation problems in the XML sche=
mas that were introduced in RFC 4826 and asks for correction."
> >=20
> > Please read the LS=2C and send your opinions to the SIMPLE list. A PDF =
is available at https://datatracker.ietf.org/documents/LIAISON/file707.pdf
> >=20
> > Thanks!
> >=20
> > Ben.
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www.ietf.org/mailman/listinfo/simple
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
 		 	   		 =20
_________________________________________________________________
Eligible CDN College & University students can upgrade to Windows 7 before =
Jan 3 for only $39.99. Upgrade now!
http://go.microsoft.com/?linkid=3D9691819=

--_446f08ac-7aa8-4acd-8263-dceef42b3593_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<=3Bas-individual>=3B

 =3B

Hi Ben=2C

 =3B

I do not have an issue 'closing out' the liason statement =3Bon behalf =
of OMA=2C however =3BIETF still has a problem 'in the large' with respe=
ct to identifying the location of =3BXML Schema's to potential implemen=
tors.

 =3B

IETF =3Brequires some mechanism (whether it be an =3Bammendment to =
the RFC =3Bdraft template) or the supplementary =3BXML Schema templ=
ate files to provide some indicator of where 'soft copies' of XML Schema's =
can be found.

 =3B

To keep the XML guru's from jumping all over this proposal=2C =3Blet me=
 be clear that I am NOT proposing the use of XML =3BSchema syntax to ac=
hieve this. =3B An informative comment=2C or =3Baddition to the RFC=
 draft template (as previously noted) to me would fit the bill =3Bperfe=
ctly. =3B Even a boilerplate statement saying (XML Schema's for RFCs ma=
y be found in the IANA XML Registry located here - =3B http://www.iana.org/as=
signments/xml-registry/schema.html) would be helpful!

 =3B

As a =3Bgood 'litmus test' poll a =3Bfew of your 'implementor buddi=
es' and ask them whether they 'realize' or 'are aware' that =3BXML =
=3BSchema for RFCs actually exist on IANA. =3B I would bet =3Bmoney=
=2C most will =3Bhave 'no clue' that =3BRFC XML Schema's exist on&n=
bsp=3BIANA's web-site. =3B =3B

 =3B

I am happy to help in the =3Beffort=2C =3Bhowever I would like =
=3Bfor IETF to not lose momentum on a fix=2C while this =3Bsubject is s=
till 'fresh' in everyone's collective minds.

 =3B

Thanks for permitting me to provide comment.

 =3B

Cheers=2C

Brian

<=3BActive Netizen>=3B.
 =3B
>=3B From: ben@estacado.net>=3B Date: Thu=2C 10 Dec 2009 15:45:40 -0600
>=3B To: simple@ietf.o=
rg
>=3B Subject: [Simple] Closure on OMA Liaison Statement (was: Liais=
on Statement from the Open Mobile Alliance)
>=3B 
>=3B <=3Bas-c=
hair>=3B
>=3B 
>=3B From the list discussion so far=2C I draw t=
he following conclusions:
>=3B 
>=3B 1) We have consensus to ask =
IANA to update the published schemas to match the definitions in RFC 4826.<=
BR>>=3B 
>=3B 2) Several people objected to adding the schemaLocatio=
n attribute. Therefore=2C we do not have consensus to make this change.
=
>=3B 
>=3B We will draw up a response to the liaison statement very =
soon=2C so if you disagree with the above conclusions=2C please make that k=
nown ASAP.
>=3B 
>=3B Thanks!
>=3B 
>=3B Ben.
>=3B=

>=3B On Oct 2=2C 2009=2C at 1:12 PM=2C Ben Campbell wrote:
>=3B=

>=3B >=3B (as SIMPLE co-chair)
>=3B >=3B 
>=3B >=3B =
OMA sent a liaison statement to the SIMPLE working group. The statement's o=
verview reads as follows:
>=3B >=3B 
>=3B >=3B "This Liaison =
Statement reports XML validation problems in the XML schemas that were intr=
oduced in RFC 4826 and asks for correction."
>=3B >=3B 
>=3B &g=
t=3B Please read the LS=2C and send your opinions to the SIMPLE list. A PDF=
 is available at https://datatracker.ietf.org/documents/LIAISON/file707.pdf=

>=3B >=3B 
>=3B >=3B Thanks!
>=3B >=3B 
>=3B >=
=3B Ben.
>=3B >=3B _______________________________________________>=3B >=3B Simple mailing list
>=3B >=3B Simple@ietf.org
>=
=3B >=3B https://www.ietf.org/mailman/listinfo/simple
>=3B 
>=
=3B _______________________________________________
>=3B Simple mailin=
g list
>=3B Simple@ietf.org
>=3B https://www.ietf.org/mailman/lis=
tinfo/simple

Get Windows 7 for only $39.99-CDN C=
ollege or University students only. This offer ends Jan 3-upgrade now!
=

--_446f08ac-7aa8-4acd-8263-dceef42b3593_--

From stpeter@stpeter.im  Wed Dec 16 08:23:59 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE27D3A6A07 for ; Wed, 16 Dec 2009 08:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8tQ6pLScxoF for ; Wed, 16 Dec 2009 08:23:57 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 98D083A6A05 for ; Wed, 16 Dec 2009 08:23:57 -0800 (PST)
Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D444240352; Wed, 16 Dec 2009 09:23:42 -0700 (MST)
Message-ID: <4B290291.6030906@stpeter.im>
Date: Wed, 16 Dec 2009 08:53:53 -0700
From: Peter Saint-Andre 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Avshalom Houri 
References:  <4B1E9F5B.9090109@stpeter.im>   
In-Reply-To: 
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020505080002080903070105"
Cc: simple@ietf.org
Subject: Re: [Simple] Suggested next	actions	with	draft-ietf-simple-interdomain-scaling-analysis
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2009 16:23:59 -0000

This is a cryptographically signed message in MIME format.

--------------ms020505080002080903070105
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

When Avshalom and I spoke recently, we discussed the idea of a "more
general" treatment of the topic of presence scalability, but did not get
into specifics of what that would mean. Here is my take...

Each of the current drafts discusses a particular technology (SIMPLE or
XMPP). However, at a higher level of abstraction I think that *any*
presence technology is going to have a non-trivial network impact,
simply because of the multiplicative nature of presence (when I come
online or change my presence or go offline, that information will be
multicasted to tens or hundreds or in my case thousands of people).

Therefore, rather than talking about SIMPLE or XMPP or any other
particular presence technology, I think it would be appropriate to
discuss at a higher level how presence behaves on the network. That
means abstracting from SIMPLE and XMPP. It means making some assumptions
about presence in general, but I think there are enough commonalities
between the presence technologies we know best to make this fairly
straightforward. It means talking about ranges with regard to the size
of presence notifications, but both of the analyses already talk about
ranges with regard to the number of buddies and other factors, so that
is not a big change. It means dropping the competition between SIMPLE
and XMPP about who's better, but that was never very productive in the
first place and we've removed the comparative stuff from the I-Ds in
question long ago. And so on.

Whether this work belongs in the SIMPLE WG or can be pursued as an
independent submission is a matter for the chairs to decide, but I'm
still convinced that it is appropriate for the IETF to analyse the
network impact of presence technologies. No, presence doesn't have the
impact of voice or video, but its impact is non-trivial and deserves to
be documented so that operators can take the impact into account when
deciding to deploy SIMPLE, XMPP, or any other technology.

Peter

On 12/16/09 3:40 AM, Avshalom Houri wrote:
> Ben,
>=20
> I am not sure if there is an example of a similar document at the IETF.=

> The idea is as described by Peter in points 3 and 4 below is to discuss=

> presence scalability in
> general and try to delay as much as possible (maybe appendixes)
> discussions on specific protocols.
>=20
> Anyway, I am not sure if there is enough support for more general
> document in the SIMPLE group
> and not sure about if there is still interest in the original document
> in the SIMPLE WG as the amount of
> responses is scanty and we do not get any numbers from real deployments=
=2E
> Are not there any deployments
> of SIMPLE?
>=20
> I am very frustrated regarding getting these type of comments from the
> IESG on the last second before it was to
> be approved as an RFC. However, I want to finish this document only mor=
e
> as honor to the amount of work that
> people have invested in this document.
>=20
> So I should assume that there is not enough support for general documen=
t
> in the SIMPLE group and I should porceed
> with the original plan as was agreed also by Cullen?
>=20
> Thanks
> --Avshalom
>=20
>=20
>=20
> From: 	Ben Campbell 
> To: 	Avshalom Houri/Haifa/IBM@IBMIL
> Cc: 	simple@ietf.org, Peter Saint-Andre 
> Date: 	11/12/2009 12:35 AM
> Subject: 	Re: [Simple] Suggested next        actions        with     =20
>  draft-ietf-simple-interdomain-scaling-analysis
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
>=20
>=20
> Hi Avshalom and Peter,
>=20
> Can you offer some examples of the sort of analyses you have in mind?
>=20
> On Dec 8, 2009, at 2:43 PM, Avshalom Houri wrote:
>=20
> In other words, does the SIMPLE WG is interested in revising the the
> interdomain-scaling draft to satisfy the last minute comments at the IE=
SG
> according to the work plan that I have sent to the list few weeks ago,
> or they would rather prefer that Peter and me will work on a new a docu=
ment
> that will merge both the SIMPLE and the XMPP scaling analysis documents=

> in a more general way as described in Peter's note below?
>=20
> --Avshalom
>=20
>=20
>=20
> _
> __simple-bounces@ietf.org_  wrote on
> 08/12/2009 08:47:55 PM:
>=20
>> From:
>>
>> Peter Saint-Andre <_stpeter@stpeter.im_ >
>>
>> To:
>>
>> Bernard Aboba <_bernard_aboba@hotmail.com_
> >
>>
>> Cc:
>>
>> _simple@ietf.org_ 
>>
>> Date:
>>
>> 08/12/2009 08:48 PM
>>
>> Subject:
>>
>> Re: [Simple] Suggested next actions with draft-ietf-simple-
>> interdomain-scaling-analysis
>>
>> Sent by:
>>
>> _simple-bounces@ietf.org_ 
>>
>> If we work on a more general analysis, perhaps there might not be next=

>> steps on draft-ietf-simple-interdomain-scaling-analysis. I think it's
>> too early to say.
>>
>> On 12/8/09 11:44 AM, Bernard Aboba wrote:
>> > I agree with all of Peter=E2=80=99s points below.
>> >
>> > =20
>> >
>> > However, this begs the question of what the next steps are on
>> >
>> > draft-ietf-simple-interdomain-scaling-analysis.
>> >
>> > =20
>> >
>> > IMHO, both draft-ietf-simple-interdomain-scaling-analysis and
>> >
>> > draft-saintandre-xmpp-presence-analysis would benefit from the
> context that
>> >
>> > Peter=E2=80=99s suggested =E2=80=9Cmore general analysis=E2=80=9D wo=
uld provide.
>> >
>> > =20
>> >
>> > Not only would that context make both documents more understandable,=
 but
>> >
>> > it would also help answer the questions posed in item #5.   =E2=80=9C=
Better
>> > numbers=E2=80=9D by
>> >
>> > themselves can=E2=80=99t accomplish that.
>> >
>> > =20
>> >
>> > =20
>> >
>> > =20
>> >
>> > Peter Saint-Andre wrote:
>> >
>> >> Avshalom and I just had a chat about this I-D. He might post in mor=
e
>> >
>> >> detail, but my main conclusions are as follows:
>> >
>> >>
>> >
>> >> 1. Analyzing the network impact of presence technologies is the
>> >
>> >> responsible thing for the IETF to do.
>> >
>> >>
>> >
>> >> 2. The analyses in draft-ietf-simple-interdomain-scaling-analysis a=
nd
>> >
>> >> draft-saintandre-xmpp-presence-analysis are not intended to force w=
ork
>> >
>> >> on optimizations, instead they are intended to frame a broader
>> >
>> >> discussion about the network impact of presence technologies.
>> >
>> >>
>> >
>> >> 3. It's unproductive to set up a competition in this regard between=

>> >
>> >> SIP and XMPP.
>> >
>> >>
>> >
>> >> 4. It would be more productive to move up a level of abstraction by=

>> >
>> >> discussing presence technologies at a higher level (not specific to=

>> >
>> >> SIP or XMPP).
>> >
>> >>
>> >
>> >> 5. A more general treatment might help protocol designers, applicat=
ion
>> >
>> >> developers, and service operators think more clearly about protocol=

>> >
>> >> optimizations, implementation improvements, and deployment sizing.
>> >
>> >> However, detailed discussion of those issues belongs somewhere else=
,
>> >
>> >> not in the general analysis document.
>> >
>> >>
>> >
>> >> If people on this list think it would be helpful, Avshalom and I ar=
e
>> >
>> >> open to working together on a more general analysis.
>> >
>> >>
>> >
>> >> Peter
>>

--------------ms020505080002080903070105
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC
B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT
aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG
EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q
UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN
AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs
hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP
XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5
wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV//
Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID
hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH
AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA
c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg
RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw
ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG
CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8
BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0
eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv
bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz
bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0
cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC
hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA
A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R
gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA
X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/
kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM
UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g
AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50
IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw
DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k
YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue
HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/
+Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1
siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz
yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9
sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud
EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV
HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy
LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH
AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF
BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk
IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0
c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV
HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/
jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh
BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk
/eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw
xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i
bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP
MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD
EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x
MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO
0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx
c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B
x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ
bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ
6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd
BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX
aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE
AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr
BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh
LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et
Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD
VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z
dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg
Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy
ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu
c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB
DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt
YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT
fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T
lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H
jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h
dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX
luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ
FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC
IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO
3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+
YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20
OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50
IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTA5MTIxNjE1NTM1M1owIwYJKoZIhvcNAQkEMRYEFBncoSQOoqjFTw8dzXmS
il9GuIQhMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ
KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw
gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg
Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAIMKE6lDFyT5ynWsa2R5PnqYT9qTKeb42ZSjQMdE9
D+qlkWfkPMEy2KtmMF8+NLYxHYSW357yeHYdBsw+P1fa3pcoPxflUQ/e6Q8I9GzgLlODzoo+
Uizy1F7OWY0LmOcYuQ0L421DembXjK8GtLAlK1XjBJhY+YsVuxia+jvdb5jtaPa5oxIscnS8
g7kb7CCAB5qDyO24Ptcm3O8tM9KqlJJfebalXht3+HahFNdqPtuTqqDyIRkMSz6LBJIsKRgW
acGGKVdcTKS9b5t3SXXVhNs62ZVAlrgo3vy4XtxELSmwdVaZeyKXe5HNXaXijyybJlV5z74k
QSghSEgNcfHAqQAAAAAAAA==
--------------ms020505080002080903070105--

From ben@estacado.net  Wed Dec 16 09:19:04 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30DF93A696B for ; Wed, 16 Dec 2009 09:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+MRl-BC12EJ for ; Wed, 16 Dec 2009 09:19:03 -0800 (PST)
Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id C4BF23A68E3 for ; Wed, 16 Dec 2009 09:19:02 -0800 (PST)
Received: from dn3-213.estacado.net (rocinante.test.estacado.net [172.16.3.213] (may be forged)) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nBGHHVMw030685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 11:17:31 -0600 (CST) (envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-8--791190005
From: Ben Campbell 
In-Reply-To: 
Date: Wed, 16 Dec 2009 11:17:31 -0600
Message-Id: 
References: , <2F8CCCCE-0CAA-4401-B0CF-25585C930D54@estacado.net> 
To: Brian McColgan 
X-Mailer: Apple Mail (2.1077)
Cc: simple@ietf.org
Subject: Re: [Simple] Closure on OMA Liaison Statement (was: Liaison Statement	from the Open Mobile Alliance)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2009 17:19:04 -0000

--Apple-Mail-8--791190005
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Are you familiar with RFC 3688? That RFC defines the XML registry at =
iana, and points to the IANA assignment page, which links to the XML =
registry itself. You can also search for the schema URN on the top level =
IANA page.

I gather you asking to make it easy for automata to find the schema, =
rather than humans. If that is the case, please note the last paragraph =
in RFC 3688 section 3.1, which indicates that the registry is not =
intended for that purpose. One could certainly write code that maps a =
schema URN into the existing registry structure, but IANA could change =
that structure at any time.

Thanks!

Ben.

On Dec 16, 2009, at 10:03 AM, Brian McColgan wrote:

> 
> =20
> Hi Ben,
> =20
> I do not have an issue 'closing out' the liason statement on behalf of =
OMA, however IETF still has a problem 'in the large' with respect to =
identifying the location of XML Schema's to potential implementors.
> =20
> IETF requires some mechanism (whether it be an ammendment to the RFC =
draft template) or the supplementary XML Schema template files to =
provide some indicator of where 'soft copies' of XML Schema's can be =
found.
> =20
> To keep the XML guru's from jumping all over this proposal, let me be =
clear that I am NOT proposing the use of XML Schema syntax to achieve =
this.  An informative comment, or addition to the RFC draft template (as =
previously noted) to me would fit the bill perfectly.  Even a =
boilerplate statement saying (XML Schema's for RFCs may be found in the =
IANA XML Registry located here -  =
http://www.iana.org/assignments/xml-registry/schema.html) would be =
helpful!
> =20
> As a good 'litmus test' poll a few of your 'implementor buddies' and =
ask them whether they 'realize' or 'are aware' that XML Schema for RFCs =
actually exist on IANA.  I would bet money, most will have 'no clue' =
that RFC XML Schema's exist on IANA's web-site. =20
> =20
> I am happy to help in the effort, however I would like for IETF to not =
lose momentum on a fix, while this subject is still 'fresh' in =
everyone's collective minds.
> =20
> Thanks for permitting me to provide comment.
> =20
> Cheers,
> Brian
> .
> =20
> > From: ben@estacado.net
> > Date: Thu, 10 Dec 2009 15:45:40 -0600
> > To: simple@ietf.org
> > Subject: [Simple] Closure on OMA Liaison Statement (was: Liaison =
Statement from the Open Mobile Alliance)
> >=20
> > 
> >=20
> > =46rom the list discussion so far, I draw the following conclusions:
> >=20
> > 1) We have consensus to ask IANA to update the published schemas to =
match the definitions in RFC 4826.
> >=20
> > 2) Several people objected to adding the schemaLocation attribute. =
Therefore, we do not have consensus to make this change.
> >=20
> > We will draw up a response to the liaison statement very soon, so if =
you disagree with the above conclusions, please make that known ASAP.
> >=20
> > Thanks!
> >=20
> > Ben.
> >=20
> > On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote:
> >=20
> > > (as SIMPLE co-chair)
> > >=20
> > > OMA sent a liaison statement to the SIMPLE working group. The =
statement's overview reads as follows:
> > >=20
> > > "This Liaison Statement reports XML validation problems in the XML =
schemas that were introduced in RFC 4826 and asks for correction."
> > >=20
> > > Please read the LS, and send your opinions to the SIMPLE list. A =
PDF is available at =
https://datatracker.ietf.org/documents/LIAISON/file707.pdf
> > >=20
> > > Thanks!
> > >=20
> > > Ben.
> > > _______________________________________________
> > > Simple mailing list
> > > Simple@ietf.org
> > > https://www.ietf.org/mailman/listinfo/simple
> >=20
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www.ietf.org/mailman/listinfo/simple
>=20
> Get Windows 7 for only $39.99-CDN College or University students only. =
This offer ends Jan 3-upgrade =
now!_______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

--Apple-Mail-8--791190005
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<as-individual>

Are you familiar =
with RFC 3688? That RFC defines the XML registry at iana, and points to =
the IANA assignment page, which links to the XML registry itself. You =
can also search for the schema URN on the top level IANA =
page.

I gather you asking to make it easy for =
automata to find the schema, rather than humans. If that is the case, =
please note the last paragraph in RFC 3688 section 3.1, which indicates =
that the registry is not intended for that purpose. One could certainly =
write code that maps a schema URN into the existing registry structure, =
but IANA could change that structure at any =
time.

Thanks!

Ben.=

On Dec 16, 2009, at 10:03 AM, Brian McColgan =
wrote:

 http://w=
ww.iana.org/assignments/xml-registry/schema.html) would be =
helpful!

As a good 'litmus test' poll a few of =
your 'implementor buddies' and ask them whether they 'realize' or 'are =
aware' that XML Schema for RFCs actually exist on IANA.  =
I would bet money, most will have 'no clue' that RFC XML =
Schema's exist on IANA's web-site.  

I am =
happy to help in the effort, however I would like for =
IETF to not lose momentum on a fix, while this subject is still =
'fresh' in everyone's collective minds.

Thanks for =
permitting me to provide =
comment.

Cheers,
Brian
<Active =
Netizen>.

> From: ben@estacado.net
> Date: Thu, =
10 Dec 2009 15:45:40 -0600
> To: simple@ietf.org
> Subject: =
[Simple] Closure on OMA Liaison Statement (was: Liaison Statement from =
the Open Mobile Alliance)
> 
> =
<as-chair>
> 
> =46rom the list =
discussion so far, I draw the following conclusions:
> 
> 1) We have =
consensus to ask IANA to update the published schemas to match the =
definitions in RFC 4826.
> 
> 2) Several people =
objected to adding the schemaLocation attribute. Therefore, we do not =
have consensus to make this change.
> 
> We will draw up a =
response to the liaison statement very soon, so if you disagree with the =
above conclusions, please make that known ASAP.
> 
> =
Thanks!
> 
>=
 Ben.
> 
> =
On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote:
> 
> > (as SIMPLE =
co-chair)
> > 
> > OMA sent a =
liaison statement to the SIMPLE working group. The statement's overview =
reads as follows:
> > 
> > "This Liaison =
Statement reports XML validation problems in the XML schemas that were =
introduced in RFC 4826 and asks for correction."
> > 
> > Please read =
the LS, and send your opinions to the SIMPLE list. A PDF is available =
at https:=
//datatracker.ietf.org/documents/LIAISON/file707.pdf
> =
> 
> > =
Thanks!
> > 
> > Ben.
> =
> _______________________________________________
> > Simple =
mailing list
> > Simple@ietf.org
> > https://www.ietf.org=
/mailman/listinfo/simple
> 
> =
_______________________________________________
> Simple mailing =
list
> Simple@ietf.org
> https://www.ietf.org=
/mailman/listinfo/simple

Get Windows 7 for only =
$39.99-CDN College or University students only. This =
offer ends Jan 3-upgrade =
now!_______________________________________________
Simple =
mailing list
Simple@ietf.org
https://www.ietf.org=
/mailman/listinfo/simple

=

--Apple-Mail-8--791190005--

From bernard_aboba@hotmail.com  Wed Dec 16 09:33:15 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98AD53A69FC for ; Wed, 16 Dec 2009 09:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.723
X-Spam-Level: 
X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlmwavdLu-gd for ; Wed, 16 Dec 2009 09:33:14 -0800 (PST)
Received: from blu0-omc4-s32.blu0.hotmail.com (blu0-omc4-s32.blu0.hotmail.com [65.55.111.171]) by core3.amsl.com (Postfix) with ESMTP id AAADE3A6977 for ; Wed, 16 Dec 2009 09:33:14 -0800 (PST)
Received: from BLU137-DS3 ([65.55.111.135]) by blu0-omc4-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 16 Dec 2009 09:33:00 -0800
X-Originating-IP: [24.19.160.219]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
From: "Bernard Aboba" 
To: 
References: 
In-Reply-To: 
Date: Wed, 16 Dec 2009 09:33:22 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acp+c9tbjUYlIvbsRc+Itbgkr7tN9gAALHtg
Content-Language: en-us
X-OriginalArrivalTime: 16 Dec 2009 17:33:00.0908 (UTC) FILETIME=[D0937AC0:01CA7E75]
Subject: Re: [Simple] Suggested next	actions with draft-ietf-simple-interdomain-scaling-analysis
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2009 17:33:15 -0000

This sounds attractive in that it will enable us to focus on the general
scaling issues without getting into a (potentially endless) debate about
the validity of particular assumptions and calculations. 

Although the resulting (more abstract) document would not be specific
to SIMPLE, as long as the performance model still applies, it seems 
plausible that this proposal could still potentially satisfy the charter
item. 

Peter said: 

"When Avshalom and I spoke recently, we discussed the idea of a "more
general" treatment of the topic of presence scalability, but did not get
into specifics of what that would mean. Here is my take...

Each of the current drafts discusses a particular technology (SIMPLE or
XMPP). However, at a higher level of abstraction I think that *any*
presence technology is going to have a non-trivial network impact,
simply because of the multiplicative nature of presence (when I come
online or change my presence or go offline, that information will be
multicasted to tens or hundreds or in my case thousands of people).

Therefore, rather than talking about SIMPLE or XMPP or any other
particular presence technology, I think it would be appropriate to
discuss at a higher level how presence behaves on the network. That
means abstracting from SIMPLE and XMPP. It means making some assumptions
about presence in general, but I think there are enough commonalities
between the presence technologies we know best to make this fairly
straightforward. It means talking about ranges with regard to the size
of presence notifications, but both of the analyses already talk about
ranges with regard to the number of buddies and other factors, so that
is not a big change. It means dropping the competition between SIMPLE
and XMPP about who's better, but that was never very productive in the
first place and we've removed the comparative stuff from the I-Ds in
question long ago. And so on.

Whether this work belongs in the SIMPLE WG or can be pursued as an
independent submission is a matter for the chairs to decide, but I'm
still convinced that it is appropriate for the IETF to analyse the
network impact of presence technologies. No, presence doesn't have the
impact of voice or video, but its impact is non-trivial and deserves to
be documented so that operators can take the impact into account when
deciding to deploy SIMPLE, XMPP, or any other technology."

From b_mccolgan@hotmail.com  Wed Dec 16 09:46:39 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3968E3A69CF for ; Wed, 16 Dec 2009 09:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level: 
X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=1.115,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AqARgGL1Q77 for ; Wed, 16 Dec 2009 09:46:37 -0800 (PST)
Received: from snt0-omc2-s24.snt0.hotmail.com (snt0-omc2-s24.snt0.hotmail.com [65.55.90.99]) by core3.amsl.com (Postfix) with ESMTP id 680DB3A69CA for ; Wed, 16 Dec 2009 09:46:37 -0800 (PST)
Received: from SNT114-W62 ([65.55.90.72]) by snt0-omc2-s24.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 16 Dec 2009 09:46:23 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_dced66a4-6b4f-4f4b-b57b-c3bbf47b6da1_"
X-Originating-IP: [208.65.73.202]
From: Brian McColgan 
To: 
Date: Wed, 16 Dec 2009 12:46:23 -0500
Importance: Normal
In-Reply-To: 
References: , <2F8CCCCE-0CAA-4401-B0CF-25585C930D54@estacado.net> , 
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Dec 2009 17:46:23.0816 (UTC) FILETIME=[AF258480:01CA7E77]
Cc: simple@ietf.org
Subject: Re: [Simple] Closure on OMA Liaison Statement (was: Liaison Statement	from the Open Mobile Alliance)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2009 17:46:39 -0000

--_dced66a4-6b4f-4f4b-b57b-c3bbf47b6da1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

Thanks Ben=2C I was not familiar with RFC 3688. =20

=20

To clarify=2C I am not asking/referring to automata.  I am referring to ind=
ividuals who implement RFC's and have a requirement to find/fetch the appli=
cable XML Schema.  That is=2C to realize a repository exists=2C and then to=
 navigate to the XML Registry so they can grab soft-copies.  They are then =
able to make use of those XML Schema's in whatever way is appropriate to th=
em.

=20

I checked my copy of the RFC draft template (i.e. the XML instance document=
 - draft-davies-template-bare.xml) and I don't see it even mentioned by def=
ault (i.e. as IETF=2C and Davies do for 'normative' mappings a-la rfc2119).

=20

I think something like a reference (at the very least a reference to RFC368=
8 in the draft RFC template) going forward (as is currently done for rfc211=
9) is the solution to this problem.

=20

Many thanks for the helpful pointers!

=20

BR/Brian.

.
=20

Subject: Re: [Simple] Closure on OMA Liaison Statement (was: Liaison Statem=
ent from the Open Mobile Alliance)
From: ben@estacado.net
Date: Wed=2C 16 Dec 2009 11:17:31 -0600
CC: simple@ietf.org
To: b_mccolgan@hotmail.com

Are you familiar with RFC 3688? That RFC defines the XML registry at iana=
=2C and points to the IANA assignment page=2C which links to the XML regist=
ry itself. You can also search for the schema URN on the top level IANA pag=
e.

I gather you asking to make it easy for automata to find the schema=2C rath=
er than humans. If that is the case=2C please note the last paragraph in RF=
C 3688 section 3.1=2C which indicates that the registry is not intended for=
 that purpose. One could certainly write code that maps a schema URN into t=
he existing registry structure=2C but IANA could change that structure at a=
ny time.

Thanks!

Ben.

On Dec 16=2C 2009=2C at 10:03 AM=2C Brian McColgan wrote:

=20
Hi Ben=2C
=20
I do not have an issue 'closing out' the liason statement on behalf of OMA=
=2C however IETF still has a problem 'in the large' with respect to identif=
ying the location of XML Schema's to potential implementors.
=20
IETF requires some mechanism (whether it be an ammendment to the RFC draft =
template) or the supplementary XML Schema template files to provide some in=
dicator of where 'soft copies' of XML Schema's can be found.
=20
To keep the XML guru's from jumping all over this proposal=2C let me be cle=
ar that I am NOT proposing the use of XML Schema syntax to achieve this.  A=
n informative comment=2C or addition to the RFC draft template (as previous=
ly noted) to me would fit the bill perfectly.  Even a boilerplate statement=
 saying (XML Schema's for RFCs may be found in the IANA XML Registry locate=
d here -  http://www.iana.org/assignments/xml-registry/schema.html) would b=
e helpful!
=20
As a good 'litmus test' poll a few of your 'implementor buddies' and ask th=
em whether they 'realize' or 'are aware' that XML Schema for RFCs actually =
exist on IANA.  I would bet money=2C most will have 'no clue' that RFC XML =
Schema's exist on IANA's web-site. =20
=20
I am happy to help in the effort=2C however I would like for IETF to not lo=
se momentum on a fix=2C while this subject is still 'fresh' in everyone's c=
ollective minds.
=20
Thanks for permitting me to provide comment.
=20
Cheers=2C
Brian
=20
> From: ben@estacado.net
> Date: Thu=2C 10 Dec 2009 15:45:40 -0600
> To: simple@ietf.org
> Subject: [Simple] Closure on OMA Liaison Statement (was: Liaison Statemen=
t from the Open Mobile Alliance)
>=20
> 
>=20
> From the list discussion so far=2C I draw the following conclusions:
>=20
> 1) We have consensus to ask IANA to update the published schemas to match=
 the definitions in RFC 4826.
>=20
> 2) Several people objected to adding the schemaLocation attribute. Theref=
ore=2C we do not have consensus to make this change.
>=20
> We will draw up a response to the liaison statement very soon=2C so if yo=
u disagree with the above conclusions=2C please make that known ASAP.
>=20
> Thanks!
>=20
> Ben.
>=20
> On Oct 2=2C 2009=2C at 1:12 PM=2C Ben Campbell wrote:
>=20
> > (as SIMPLE co-chair)
> >=20
> > OMA sent a liaison statement to the SIMPLE working group. The statement=
's overview reads as follows:
> >=20
> > "This Liaison Statement reports XML validation problems in the XML sche=
mas that were introduced in RFC 4826 and asks for correction."
> >=20
> > Please read the LS=2C and send your opinions to the SIMPLE list. A PDF =
is available at https://datatracker.ietf.org/documents/LIAISON/file707.pdf
> >=20
> > Thanks!
> >=20
> > Ben.
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www.ietf.org/mailman/listinfo/simple
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

Get Windows 7 for only $39.99-CDN College or University students only. This=
 offer ends Jan 3-upgrade now!_____________________________________________=
__
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

 		 	   		 =20
_________________________________________________________________
Eligible CDN College & University students can upgrade to Windows 7 before =
Jan 3 for only $39.99. Upgrade now!
http://go.microsoft.com/?linkid=3D9691819=

--_dced66a4-6b4f-4f4b-b57b-c3bbf47b6da1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<=3Bas-individual>=3B

 =3B

Thanks Ben=2C I was not familiar with RFC 3688. =3B 

 =3B

To clarify=2C I am not asking/referring to =3Bautomata. =3B I am re=
ferring to =3Bindividuals who implement RFC's and =3Bhave a require=
ment to =3Bfind/fetch the applicable XML Schema. =3B That is=2C to =
realize =3Ba repository exists=2C and then =3Bto navigate to the XM=
L Registry so they can grab soft-copies. =3B They are then able to make=
 use of those XML Schema's =3Bin whatever way is appropriate to them.
 =3B

I checked my copy of the RFC draft template (i.e. the XML instance document=
 - draft-davies-template-bare.xml) and I don't see it =3Beven mentioned=
 by default (i.e. as IETF=2C and Davies =3Bdo for =3B'normative' ma=
ppings =3Ba-la rfc2119).

 =3B

I think something like a reference (at the very least a reference to RFC368=
8 in the draft RFC template) =3Bgoing forward (as is currently done for=
 =3Brfc2119) is the solution to this problem.

 =3B

Many thanks for the helpful pointers!

 =3B

BR/Brian.

<=3BActive Netizen>=3B.
 =3B

Subject: Re: [Simple] Closure on OMA Liaison Statement (was: Liaison Statem=
ent from the Open Mobile Alliance)
From: ben@estacado.net
Date: Wed=
=2C 16 Dec 2009 11:17:31 -0600
CC: simple@ietf.org
To: b_mccolgan@hot=
mail.com

<=3Bas-individual>=3B

Are you familiar with RFC 3688? That RFC defines the XML registry at i=
ana=2C and points to the IANA assignment page=2C which links to the XML reg=
istry itself. You can also search for the schema URN on the top level IANA =
page.

I gather you asking to make it easy for automata to find the schema=2C=
 rather than humans. If that is the case=2C please note the last paragraph =
in RFC 3688 section 3.1=2C which indicates that the registry is not intende=
d for that purpose. One could certainly write code that maps a schema URN i=
nto the existing registry structure=2C but IANA could change that structure=
 at any time.

Thanks!

Ben.

On Dec 16=2C 2009=2C at 10:03 AM=2C Brian McColgan wrote:

<=3Bas-individual>=3B
 =3B
Hi Ben=2C
 =3B
I do not=
 have an issue 'closing out' the liason statement =3Bon behalf of OMA=
=2C however =3BIETF still has a problem 'in the large' with respect to =
identifying the location of =3BXML Schema's to potential implementors.<=
BR> =3B
IETF =3Brequires some mechanism (whether it be an =
=3Bammendment to the RFC =3Bdraft template) or the supplementary =
=3BXML Schema template files to provide some indicator of where 'soft copie=
s' of XML Schema's can be found.
 =3B
To keep the XML guru's from=
 jumping all over this proposal=2C =3Blet me be clear that I am NOT pro=
posing the use of XML =3BSchema syntax to achieve this. =3B An info=
rmative comment=2C or =3Baddition to the RFC draft template (as previou=
sly noted) to me would fit the bill =3Bperfectly. =3B Even a boiler=
plate statement saying (XML Schema's for RFCs may be found in the IANA XML =
Registry located here - =3B =
=3Bhttp://www.iana.org/assignments/xml-registry/schema.html) would be =
helpful!
 =3B
As a =3Bgood 'litmus test' poll a =3Bfew of=
 your 'implementor buddies' and ask them whether they 'realize' or 'are awa=
re' that =3BXML =3BSchema for RFCs actually exist on IANA. =3B =
I would bet =3Bmoney=2C most will =3Bhave 'no clue' that =3BRFC=
 XML Schema's exist on =3BIANA's web-site. =3B =3B
 =3B<=
BR>I am happy to help in the =3Beffort=2C =3Bhowever I would like&n=
bsp=3Bfor IETF to not lose momentum on a fix=2C while this =3Bsubject i=
s still 'fresh' in everyone's collective minds.
 =3B
Thanks for p=
ermitting me to provide comment.
 =3B
Cheers=2C
Brian
 =
=3B
>=3B From: =3Bben@estacado.net
>=3B Date: Thu=
=2C 10 Dec 2009 15:45:40 -0600
>=3B To: =3Bsimple@ietf.org
>=3B Subject: [Simple] Closure on OMA Liaison Statement (was: Liais=
on Statement from the Open Mobile Alliance)
>=3B =3B
>=3B <=3Bas-chair>=3B
>=3B =3B
>=3B From the lis=
t discussion so far=2C I draw the following conclusions:
>=3B =3B
>=3B 1) We have consensu=
s to ask IANA to update the published schemas to match the definitions in R=
FC 4826.
>=3B =3B>=3B 2) Several people objected to adding the schemaLocation attribute. =
Therefore=2C we do not have consensus to make this change.
>=3B =3B
>=3B We will draw up a=
 response to the liaison statement very soon=2C so if you disagree with the=
 above conclusions=2C please make that known ASAP.
>=3B =3B
>=3B Thanks!
>=3B =3B
>=3B Ben.
>=3B =3B
>=3B On Oct 2=2C 20=
09=2C at 1:12 PM=2C Ben Campbell wrote:
>=3B =3B
>=3B >=3B (as SIMPLE co-chair)
>=
=3B >=3B =3B
>=3B =
>=3B OMA sent a liaison statement to the SIMPLE working group. The statem=
ent's overview reads as follows:
>=3B >=3B =3B
>=3B >=3B "This Liaison Statement repor=
ts XML validation problems in the XML schemas that were introduced in RFC 4=
826 and asks for correction."
>=3B >=3B =3B
>=3B >=3B Please read the LS=2C and send y=
our opinions to the SIMPLE list. A PDF is available at =3Bhttps://datatracker.ietf.org/documents/LIAISON=
/file707.pdf
>=3B >=3B&nb=
sp=3B
>=3B >=3B Thanks!
>=3B >=3B =3B
>=3B >=3B Ben.
>=3B >=3B __=
_____________________________________________
>=3B >=3B Simple maili=
ng list
>=3B >=3B =3BSimple@ietf.org
>=3B >=3B<=
SPAN class=3DecxApple-converted-space> =3Bhttps://www.ietf.org/mailman/listinfo/si=
mple
>=3B =3B>=3B _______________________________________________
>=3B Simple ma=
iling list
>=3B =3B<=
A href=3D"mailto:Simple@ietf.org">Simple@ietf.org
>=3B =3Bhttps://www.ietf.org/mailman/listinfo/simple

Get Windows 7 for only $39.99-CDN College or University students only. =3BThis offer ends Jan 3-upgrade now!_________=
______________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple<=
/A>

Get Wind=
ows 7 for only $39.99-CDN College or University students only. This offer ends J=
an 3-upgrade now!
=

--_dced66a4-6b4f-4f4b-b57b-c3bbf47b6da1_--

From miguel.a.garcia@ericsson.com  Thu Dec 17 02:45:58 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1F328C0F8 for ; Thu, 17 Dec 2009 02:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNwoa-t0b159 for ; Thu, 17 Dec 2009 02:45:57 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 01EFC28C0EA for ; Thu, 17 Dec 2009 02:45:56 -0800 (PST)
X-AuditID: c1b4fb24-b7beeae000003a71-c3-4b2a0bd5ee06
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id ED.FE.14961.5DB0A2B4; Thu, 17 Dec 2009 11:45:41 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 17 Dec 2009 11:44:28 +0100
Received: from [159.107.24.242] ([159.107.24.242]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 17 Dec 2009 11:44:28 +0100
Message-ID: <4B2A0B8B.50206@ericsson.com>
Date: Thu, 17 Dec 2009 11:44:27 +0100
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Aki Niemi ,  Geir Arne Sandbakken 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Dec 2009 10:44:28.0527 (UTC) FILETIME=[E878B7F0:01CA7F05]
X-Brightmail-Tracker: AAAAAA==
Cc: Simple WG 
Subject: [Simple] Review of draft-ietf-simple-chat-05.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2009 10:45:58 -0000

I review the latest version of the draft-ietf-simple-chat-05. I have only 
a suggestion to better improve the understanding of outsiders:

-  The reader can be confused and think that participants learn other 
partipants' nicknames in received MSRP SEND messages. In other words, one 
can think that a received MSRP SEND message contains the nickname of the 
sender. However, the approach the draft describes is different: a 
participant learns other participants' nicknames through a notification 
to the conference event package. This requires each participant to map 
nicknames to other participants' SIP URIs. It is the endpoint's 
responsibility to map a sender's URI to a nickname and display it 
accordingly to the user. This fact should deserve a couple of explanatory 
paragraphs at the beginning of Section 7.

- In Section 9.4, the paragraph that describes flow F1, the text reads:

    She
    addresses the CPIM message to the Bob's nickname, which she learned
    from a notification in the conference event package.

It is incorrect to say that a CPIM message is addressed to Bob's 
nickname. Section 6.1 indicates the types of identities that can be used 
in CPIM messages, and these do not include nicknames. ONLY URIs are allowed.

- I noticed that in many CPM messages examples the draft uses the 
following two SIP URIs:

   sip:Alice%20in%20wonderland@example.com
   sip:Bob%20the%great@example.com

   While these are valid SIP URIs, the reader can confuse them with 
nicknames embedded in SIP URIs (a feature that is no longer in this 
version of the draft). Therefore, I would suggest to replace them more 
common SIP URIs:

   sip:alice@example.com
   sip:bob@example.com

- Section 9.5 shows an example of a chuncked private message. If this is 
the purpose of the example, I suggest to replace the GRUU in the From 
header of the CPIM message with a regular URI. We have Section 9.6 to 
show an example of using GRUUs, so no need to mix concepts in the example.

- Figure 20 misses the Flow 4, presumably a 200 response for the MSRP SEND 3.

- In Section 5.2, penultimate paragraph, the text reads:

    The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu
    [I-D.ietf-sip-gruu].

I don't know which recommendation if the GRUU draft the text is referring 
to, so this isn't going to be implemented. The suggestion is to 
explicitly refer to the recommendation (whichever it is).

I also have a number of editorial comments, but these are of no interest 
to the list.

BR,

       Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From geir.sandbakken@tandberg.com  Thu Dec 17 05:15:30 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD463A6897 for ; Thu, 17 Dec 2009 05:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rAL9L3b6Lpq for ; Thu, 17 Dec 2009 05:15:29 -0800 (PST)
Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by core3.amsl.com (Postfix) with SMTP id 39D573A67A6 for ; Thu, 17 Dec 2009 05:15:28 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: geir.sandbakken@tandberg.com
X-Msg-Ref: server-13.tower-178.messagelabs.com!1261055713!22654980!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [62.70.2.252]
Received: (qmail 13680 invoked from network); 17 Dec 2009 13:15:14 -0000
Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-13.tower-178.messagelabs.com with SMTP; 17 Dec 2009 13:15:14 -0000
Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 14:15:13 +0100
Received: from [10.47.2.169] (GSandbakkenT61.rd.tandberg.com [10.47.2.169]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id nBHDFDSI018489;  Thu, 17 Dec 2009 14:15:13 +0100
Message-ID: <4B2A2EE1.7050206@tandberg.com>
Date: Thu, 17 Dec 2009 14:15:13 +0100
From: Geir Arne Sandbakken 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "Miguel A. Garcia" 
References: <4B2A0B8B.50206@ericsson.com>
In-Reply-To: <4B2A0B8B.50206@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Dec 2009 13:15:13.0727 (UTC) FILETIME=[F7D4B4F0:01CA7F1A]
Cc: Aki Niemi , Simple WG 
Subject: Re: [Simple] Review of draft-ietf-simple-chat-05.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2009 13:15:30 -0000

Miguel,

Thank you very much for the review.  Comments inline.

Miguel A. Garcia wrote:
> I review the latest version of the draft-ietf-simple-chat-05. I have 
> only a suggestion to better improve the understanding of outsiders:
>
> -  The reader can be confused and think that participants learn other 
> partipants' nicknames in received MSRP SEND messages. In other words, 
> one can think that a received MSRP SEND message contains the nickname 
> of the sender. However, the approach the draft describes is different: 
> a participant learns other participants' nicknames through a 
> notification to the conference event package. This requires each 
> participant to map nicknames to other participants' SIP URIs. It is 
> the endpoint's responsibility to map a sender's URI to a nickname and 
> display it accordingly to the user. This fact should deserve a couple 
> of explanatory paragraphs at the beginning of Section 7.
>
> - In Section 9.4, the paragraph that describes flow F1, the text reads:
>
>    She
>    addresses the CPIM message to the Bob's nickname, which she learned
>    from a notification in the conference event package.
> It is incorrect to say that a CPIM message is addressed to Bob's 
> nickname. Section 6.1 indicates the types of identities that can be 
> used in CPIM messages, and these do not include nicknames. ONLY URIs 
> are allowed.
Yes, this wording was right for a previous revision of the draft, but 
not any more.  I will change it so no nickname terminology are mentioned 
together with the CPIM messages at all.

> - I noticed that in many CPM messages examples the draft uses the 
> following two SIP URIs:
>
>   sip:Alice%20in%20wonderland@example.com
>   sip:Bob%20the%great@example.com
>
>   While these are valid SIP URIs, the reader can confuse them with 
> nicknames embedded in SIP URIs (a feature that is no longer in this 
> version of the draft). Therefore, I would suggest to replace them more 
> common SIP URIs:
>
>   sip:alice@example.com
>   sip:bob@example.com
Agree, and fixed.  This mistake has already created confusion.

> - Section 9.5 shows an example of a chuncked private message. If this 
> is the purpose of the example, I suggest to replace the GRUU in the 
> From header of the CPIM message with a regular URI. We have Section 
> 9.6 to show an example of using GRUUs, so no need to mix concepts in 
> the example.
>
> - Figure 20 misses the Flow 4, presumably a 200 response for the MSRP 
> SEND 3.
>
> - In Section 5.2, penultimate paragraph, the text reads:
>
>    The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu
>    [I-D.ietf-sip-gruu].
>
> I don't know which recommendation if the GRUU draft the text is 
> referring to, so this isn't going to be implemented. The suggestion is 
> to explicitly refer to the recommendation (whichever it is).
The allocation of anonymous URIs is no longer part of the specification, 
and all references to GRUU have been removed from the draft.

> I also have a number of editorial comments, but these are of no 
> interest to the list.
Thanks!
>
> BR,
>
>       Miguel
Thanks,
Geir Arne

From christer.holmberg@ericsson.com  Thu Dec 17 05:33:50 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4607828C117 for ; Thu, 17 Dec 2009 05:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.217
X-Spam-Level: 
X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK6OPnjsPgFP for ; Thu, 17 Dec 2009 05:33:48 -0800 (PST)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F09DA3A685A for ; Thu, 17 Dec 2009 05:33:47 -0800 (PST)
X-AuditID: c1b4fb3c-b7b57ae0000005bb-94-4b2a332c8c60
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id AA.4C.01467.C233A2B4; Thu, 17 Dec 2009 14:33:32 +0100 (CET)
Received: from ESESSCMS0354.eemea.ericsson.se ([153.88.115.166]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 17 Dec 2009 14:33:32 +0100
From: Christer Holmberg 
To: "simple@ietf.org" 
Date: Thu, 17 Dec 2009 14:33:30 +0100
Thread-Topic: Draft new versions: msrp-acm and sessmatch
Thread-Index: Acp/HYWJ2937C3iwRvOnVUmw7FgrMQ==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC743C55019627ESESSCMS0354e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [Simple] Draft new versions: msrp-acm and sessmatch
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2009 13:33:50 -0000

--_000_FF84A09F50A6DC48ACB6714F4666CC743C55019627ESESSCMS0354e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Based on the WGLC comments, I have submitted new versions of draft-ietf-sim=
ple-msrp-acm (-03) and draft-ietf-simple-msrp-sessmatch (-01).

The drafts can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-03.txt
http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-sessmatch-01.=
txt

Regards,

Christer

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

Hi,

Based on the WGLC comments, I have submitted new vers=
ions of draft-ietf-simple-msrp-acm (-03) and draft-ietf-simple-msrp-sessmat=
ch (-01).

The drafts can also be found at:

http://users.piu=
ha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-03.txt

http://use=
rs.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-sessmatch-01.txt

Regards,

Christer

--_000_FF84A09F50A6DC48ACB6714F4666CC743C55019627ESESSCMS0354e_--

From root@core3.amsl.com  Thu Dec 17 05:45:01 2009
Return-Path: 
X-Original-To: simple@ietf.org
Delivered-To: simple@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id BABB73A6A4A; Thu, 17 Dec 2009 05:45:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20091217134501.BABB73A6A4A@core3.amsl.com>
Date: Thu, 17 Dec 2009 05:45:01 -0800 (PST)
Cc: simple@ietf.org
Subject: [Simple] I-D Action:draft-ietf-simple-msrp-acm-03.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2009 13:45:01 -0000

--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           : An Alternative Connection Model for the Message Session Relay Protocol (MSRP)
	Author(s)       : C. Holmberg, S. Blau
	Filename        : draft-ietf-simple-msrp-acm-03.txt
	Pages           : 8
	Date            : 2009-12-17

This document defines an alternative connection model for MSRP UAs,
which uses COMEDIA in order to create the MSRP transport connection.
The model allows MSRP UAs behind NATs to negotiate which UA will
initiate the establishment of the TCP connection, in order for MSRP
messages to traverse the NAT.  The document also defines how an MSRP
UA which is located behind a NAT keeps the NAT binding alive.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 20, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-simple-msrp-acm-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-12-17053114.I-D@ietf.org>

--NextPart--

From root@core3.amsl.com  Thu Dec 17 05:45:01 2009
Return-Path: 
X-Original-To: simple@ietf.org
Delivered-To: simple@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id C3C6B3A6A67; Thu, 17 Dec 2009 05:45:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20091217134501.C3C6B3A6A67@core3.amsl.com>
Date: Thu, 17 Dec 2009 05:45:01 -0800 (PST)
Cc: simple@ietf.org
Subject: [Simple] I-D Action:draft-ietf-simple-msrp-sessmatch-01.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2009 13:45:01 -0000

--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           : Session Matching Update for the Message Session Relay Protocol (MSRP)
	Author(s)       : C. Holmberg, S. Blau
	Filename        : draft-ietf-simple-msrp-sessmatch-01.txt
	Pages           : 6
	Date            : 2009-12-17

This document updates the session matching procedure defined in
section 7.3 of RFC 4975, so that an MSRP UA only uses the session-id
part of the MSRP URI in order to perform the consistency checks.  The
update allows intermediaries (ALGs) to modify the address information
in the MSRP URI of the SDP a=path attribute, without the need for the
intermediaries to terminate and do the correlating modifications in
the associated MSRP messages.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 20, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-simple-msrp-sessmatch-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-12-17053137.I-D@ietf.org>

--NextPart--

From ben@estacado.net  Fri Dec 18 14:52:06 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620803A694E for ; Fri, 18 Dec 2009 14:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXxUeDzHBqNI for ; Fri, 18 Dec 2009 14:52:05 -0800 (PST)
Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 8F0DA3A68D0 for ; Fri, 18 Dec 2009 14:52:05 -0800 (PST)
Received: from [172.16.3.213] (rocinante.test.estacado.net [172.16.3.213] (may be forged)) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nBIMoZYb097629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 Dec 2009 16:50:35 -0600 (CST) (envelope-from ben@estacado.net)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: Ben Campbell 
In-Reply-To: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com>
Date: Fri, 18 Dec 2009 16:50:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <58661C40-6606-4F61-89C1-A5CC46AC383E@estacado.net>
References: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com>
To: Simple WG 
X-Mailer: Apple Mail (2.1077)
Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2009 22:52:06 -0000

Oops, please forgive the typo on the sessmatch URI below. There should =
be no "t" on the end.

On Dec 9, 2009, at 1:25 PM, Ben Campbell wrote:

> This is a Working Group Last Call on the msrp-acm and =
msrp-sessionmatch drafts. We are last-calling them as a unit:
>=20
> http://tools.ietf.org/html/draft-ietf-simple-msrp-acm-02
> http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-00t
>=20
> The WGLC will conclude on 23 December 2009. Please send your comments, =
including NITS and "this is ready to go" type comments, to the authors =
and the working group.
>=20
> Thanks!
>=20
> Ben.
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

From ben@estacado.net  Fri Dec 18 15:14:53 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4953A696B for ; Fri, 18 Dec 2009 15:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level: 
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTMq48G4168X for ; Fri, 18 Dec 2009 15:14:52 -0800 (PST)
Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 338073A6778 for ; Fri, 18 Dec 2009 15:14:52 -0800 (PST)
Received: from [172.16.3.213] (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nBINDBPX002134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Dec 2009 17:13:17 -0600 (CST) (envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=windows-1252
From: Ben Campbell 
In-Reply-To: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com>
Date: Fri, 18 Dec 2009 17:13:11 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BA83419-CE5E-4677-99F7-9B19F8863DCD@estacado.net>
References: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com>
To: Simple WG 
X-Mailer: Apple Mail (2.1077)
Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2009 23:14:53 -0000

(Since Christer submitted updates to both drafts, I have reviewed =
msrp-acm-03 and sessmatch-01)

Both of these drafts are nearly ready to progress, but I think there are =
a few open issues that are minor, but still substantive.

-------------------- WGLC review of draft-ietf-simple-msrp-acm-03:

** Substantive:

-- Section 3:

I'd like to see something to the effect of "Support of this =
specification is optional for MSRP user agents in general. User Agents =
that are likely to be deployed without MSRP Relays SHOULD support this =
specification in order to improve the odds of being able to communicate =
across NATs."

-- Section 4.2, 4th paragraph from end:

I'm not entirely sure it's safe to assume that the presence or absence =
of a NAT on the signaling path always indicates the same for the media =
path. For example, there could be a SIP proxy _inside_ the NAT.

-- Section 4.3:

 Did we ever close on the COMEDIA-TLS fingerprint requirement, and how =
that could be a problem in the presence of relays?

-- Section 4.4, third paragraph (NOTE about ICE)

Is the note really needed? This draft is not about using ICE per se.

-- Section 5:

Does it make sense to use STUN for this in a TCP stream?

Do we need some statement about not sending a keepalive mid-chunk? (I'm =
not sure why one would need to, but doing so is likely to corrupt a =
message.) Also, does the default Tr value in ICE apply to TCP?

-- Section 6:

Have we thought through whether changing the active party has any impact =
on TLS security? Does this interact with key fingerprints in the =
signaling channel? (I'm not saying that I know it does--I just want to =
make sure we've thought about it.)

** Editorial and Nits:

-- General:

Please expand non-common-knowledge acronyms on first mention.=20

-- section 1, first two paragraphs:

These would be easier to read if the references were structured as truly =
parenthetical rather than as bona-fide parts of the sentence. For =
example, "The Message Session Relay Protocol (MSRP) [ref] defines that=85"=
 rather than "[ref] defines that=85"

-- section 1, paragraph 2:

ben: s/"responsible to create"/"responsible for creating"

-- section 1, paragraph 4 (OMA example)

By "located in the network", do you mean carrier network? Publicly =
accessible network?

-- section 1, last paragraph:

Am I correct in assuming this would not be limited to TCP? For example, =
if we define an SCTP binding in the future, COMEDIA could still apply? =
If so, perhaps it would be better to consistently refer to transport =
connections rather than TCP connections.

-- section 3, paragraph 1:

s/interop/interoperate (or interwork).=20

Also, I tend to think of UAs conforming to this spec as (mostly) also =
conforming to RFC4975. So I'm not sure "[RFC 4975] conformant" is the =
best way to refer to UAs that do not implement COMEDIA. Perhaps =
something along the lines of "=85 from a UA that follows the RFC 4975 =
connection model=85"

-- section 4.2, paragraph 1:

We still need to make it more clear that the normative language in this =
spec is scoped to UAs supporting COMEDIA, i.e. this MUST is not =
universal. That might be doable by being a little more precise in the =
applicability statement (see my comment on section 3). Otherwise, we =
need some concise term that means "MSRP UAs implementing COMEDIA"

-- section 4.2, paragraph 2:

ben:s/"which is not=85"/"that is not..."

-- section 4.2, fifth paragraph from end (starting with - the UA has =
used STUN)
s/signalling/signaling
Can we have an informational reference for STUN?

-- idnits returns some warnings that should be fixed prior to pubreq.

-------------------- WGLC review of =
draft-ietf-simple-msrp-sessionmatch-01:

*** Substantive:

-- Section 5:

I think we need another paragraph along the lines of:

"An MSRP UA treats its session URI as a shared secret to determine that =
an incoming transport connection is indeed from the signaled peer =
device. An MSRP session URI therefore needs to be hard to guess. =
However, RFC 4975 already requires the session-id part of the URI to be =
sufficiently hard to guess. Furthermore, the addressing information in =
the domain part of the URI is relatively easy to guess. This makes the =
difficulty in guessing the session-id roughly equivalent to the =
difficulty of guessing the entire URI."

-- Section 5, last paragraph:

Do we need to talk about the security issues created by the =
intermediaries themselves? We don't otherwise specify how intermediaries =
work in this draft.

** Editorial and Nits:

-- General:

Please expand acronyms on first mention.

-- Section 1, paragraph 3:

I'm not sure I follow the "- NAPT - " part of the last sentence.

-- Section 4.1 and 4.2

Either need to state that 4.2 replaces the first paragraph in section =
7.3, or state that it replaces the entire section and include the (one =
sentence) second paragraph from that section.

-- Section 8.1:

I'm not sure the references are right here.=20

-- Section 8.2

Can we have an nformative reference to TS23.228?

-- idnits returns some warnings--please check them before pubreq.

On Dec 9, 2009, at 1:25 PM, Ben Campbell wrote:

> This is a Working Group Last Call on the msrp-acm and =
msrp-sessionmatch drafts. We are last-calling them as a unit:
>=20
> http://tools.ietf.org/html/draft-ietf-simple-msrp-acm-02
> http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-00t
>=20
> The WGLC will conclude on 23 December 2009. Please send your comments, =
including NITS and "this is ready to go" type comments, to the authors =
and the working group.
>=20
> Thanks!
>=20
> Ben.
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

From ben@nostrum.com  Fri Dec 18 15:15:28 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DBB3A696B for ; Fri, 18 Dec 2009 15:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.398,  BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y5y1zmdawII for ; Fri, 18 Dec 2009 15:15:27 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 616F728C0E6 for ; Fri, 18 Dec 2009 15:15:26 -0800 (PST)
Received: from [172.16.3.213] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nBINF5um075661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Dec 2009 17:15:05 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=windows-1252
From: Ben Campbell 
In-Reply-To: <7BA83419-CE5E-4677-99F7-9B19F8863DCD@estacado.net>
Date: Fri, 18 Dec 2009 17:15:05 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com> <7BA83419-CE5E-4677-99F7-9B19F8863DCD@estacado.net>
To: Simple WG 
X-Mailer: Apple Mail (2.1077)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2009 23:15:28 -0000

(And of course, that entire review was as an individual contributor.)

On Dec 18, 2009, at 5:13 PM, Ben Campbell wrote:

> (Since Christer submitted updates to both drafts, I have reviewed =
msrp-acm-03 and sessmatch-01)
>=20
> Both of these drafts are nearly ready to progress, but I think there =
are a few open issues that are minor, but still substantive.
>=20
>=20
> -------------------- WGLC review of draft-ietf-simple-msrp-acm-03:
>=20
> ** Substantive:
>=20
> -- Section 3:
>=20
> I'd like to see something to the effect of "Support of this =
specification is optional for MSRP user agents in general. User Agents =
that are likely to be deployed without MSRP Relays SHOULD support this =
specification in order to improve the odds of being able to communicate =
across NATs."
>=20
> -- Section 4.2, 4th paragraph from end:
>=20
> I'm not entirely sure it's safe to assume that the presence or absence =
of a NAT on the signaling path always indicates the same for the media =
path. For example, there could be a SIP proxy _inside_ the NAT.
>=20
> -- Section 4.3:
>=20
> Did we ever close on the COMEDIA-TLS fingerprint requirement, and how =
that could be a problem in the presence of relays?
>=20
> -- Section 4.4, third paragraph (NOTE about ICE)
>=20
> Is the note really needed? This draft is not about using ICE per se.
>=20
> -- Section 5:
>=20
> Does it make sense to use STUN for this in a TCP stream?
>=20
> Do we need some statement about not sending a keepalive mid-chunk? =
(I'm not sure why one would need to, but doing so is likely to corrupt a =
message.) Also, does the default Tr value in ICE apply to TCP?
>=20
> -- Section 6:
>=20
> Have we thought through whether changing the active party has any =
impact on TLS security? Does this interact with key fingerprints in the =
signaling channel? (I'm not saying that I know it does--I just want to =
make sure we've thought about it.)
>=20
>=20
> ** Editorial and Nits:
>=20
> -- General:
>=20
> Please expand non-common-knowledge acronyms on first mention.=20
>=20
> -- section 1, first two paragraphs:
>=20
> These would be easier to read if the references were structured as =
truly parenthetical rather than as bona-fide parts of the sentence. For =
example, "The Message Session Relay Protocol (MSRP) [ref] defines that=85"=
 rather than "[ref] defines that=85"
>=20
> -- section 1, paragraph 2:
>=20
> ben: s/"responsible to create"/"responsible for creating"
>=20
> -- section 1, paragraph 4 (OMA example)
>=20
> By "located in the network", do you mean carrier network? Publicly =
accessible network?
>=20
> -- section 1, last paragraph:
>=20
> Am I correct in assuming this would not be limited to TCP? For =
example, if we define an SCTP binding in the future, COMEDIA could still =
apply? If so, perhaps it would be better to consistently refer to =
transport connections rather than TCP connections.
>=20
> -- section 3, paragraph 1:
>=20
> s/interop/interoperate (or interwork).=20
>=20
> Also, I tend to think of UAs conforming to this spec as (mostly) also =
conforming to RFC4975. So I'm not sure "[RFC 4975] conformant" is the =
best way to refer to UAs that do not implement COMEDIA. Perhaps =
something along the lines of "=85 from a UA that follows the RFC 4975 =
connection model=85"
>=20
> -- section 4.2, paragraph 1:
>=20
> We still need to make it more clear that the normative language in =
this spec is scoped to UAs supporting COMEDIA, i.e. this MUST is not =
universal. That might be doable by being a little more precise in the =
applicability statement (see my comment on section 3). Otherwise, we =
need some concise term that means "MSRP UAs implementing COMEDIA"
>=20
> -- section 4.2, paragraph 2:
>=20
> ben:s/"which is not=85"/"that is not..."
>=20
> -- section 4.2, fifth paragraph from end (starting with - the UA has =
used STUN)
> s/signalling/signaling
> Can we have an informational reference for STUN?
>=20
> -- idnits returns some warnings that should be fixed prior to pubreq.
>=20
>=20
>=20
> -------------------- WGLC review of =
draft-ietf-simple-msrp-sessionmatch-01:
>=20
>=20
> *** Substantive:
>=20
> -- Section 5:
>=20
> I think we need another paragraph along the lines of:
>=20
> "An MSRP UA treats its session URI as a shared secret to determine =
that an incoming transport connection is indeed from the signaled peer =
device. An MSRP session URI therefore needs to be hard to guess. =
However, RFC 4975 already requires the session-id part of the URI to be =
sufficiently hard to guess. Furthermore, the addressing information in =
the domain part of the URI is relatively easy to guess. This makes the =
difficulty in guessing the session-id roughly equivalent to the =
difficulty of guessing the entire URI."
>=20
> -- Section 5, last paragraph:
>=20
> Do we need to talk about the security issues created by the =
intermediaries themselves? We don't otherwise specify how intermediaries =
work in this draft.
>=20
>=20
>=20
> ** Editorial and Nits:
>=20
> -- General:
>=20
> Please expand acronyms on first mention.
>=20
> -- Section 1, paragraph 3:
>=20
> I'm not sure I follow the "- NAPT - " part of the last sentence.
>=20
> -- Section 4.1 and 4.2
>=20
> Either need to state that 4.2 replaces the first paragraph in section =
7.3, or state that it replaces the entire section and include the (one =
sentence) second paragraph from that section.
>=20
> -- Section 8.1:
>=20
> I'm not sure the references are right here.=20
>=20
> -- Section 8.2
>=20
> Can we have an nformative reference to TS23.228?
>=20
>=20
> -- idnits returns some warnings--please check them before pubreq.
>=20
>=20
>=20
>=20
> On Dec 9, 2009, at 1:25 PM, Ben Campbell wrote:
>=20
>> This is a Working Group Last Call on the msrp-acm and =
msrp-sessionmatch drafts. We are last-calling them as a unit:
>>=20
>> http://tools.ietf.org/html/draft-ietf-simple-msrp-acm-02
>> http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-00t
>>=20
>> The WGLC will conclude on 23 December 2009. Please send your =
comments, including NITS and "this is ready to go" type comments, to the =
authors and the working group.
>>=20
>> Thanks!
>>=20
>> Ben.
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
>=20

From adam@estacado.net  Mon Dec 21 15:25:30 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2495D3A682C for ; Mon, 21 Dec 2009 15:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLrmD3NkTM0L for ; Mon, 21 Dec 2009 15:25:29 -0800 (PST)
Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 164DD3A69B6 for ; Mon, 21 Dec 2009 15:25:28 -0800 (PST)
Received: from [172.16.3.231] (orthrus.test.estacado.net [172.16.3.231] (may be forged)) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nBLNNum1075077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 17:23:56 -0600 (CST) (envelope-from adam@estacado.net)
Message-ID: <4B30038C.7020308@estacado.net>
Date: Mon, 21 Dec 2009 17:23:56 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Ben Campbell 
References: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com>
In-Reply-To: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Simple WG , draft-ietf-simple-msrp-acm@tools.ietf.org
Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2009 23:25:30 -0000

On 12/9/09 13:25, Dec 9, Ben Campbell wrote:
> This is a Working Group Last Call on the msrp-acm and msrp-sessionmatch drafts. We are last-calling them as a unit:
>    

Just for clarification: the fact that we're last calling these at the 
same time doesn't mean that we intend them to progress as a cluster 
(http://www.rfc-editor.org/cluster_def.html), does it? There is no 
normative dependency between them, and I'd hate to see them both be 
delayed due to issues related to only one of them (e.g., in IETF last 
call, or IESG review).

==========
draft-ietf-simple-msrp-acm

   1. NIT: The abstract contains several acronyms that need to be
      expanded (MSRP, UA, COMEDIA) -- see section 3.6 of
      http://www.rfc-editor.org/rfc-style-guide/rfc-style

   2. NIT: In the introduction, the sentence "[RFC4975] also allows, but
      does not define, MSRP UAs to use other mechanisms in order to
      create the MSRP transport connection" lacks parallelism. Try
      "[RFC4975] also allows, but does not define, alternate mechanisms
      for MSRP UAs to create MSRP transport connections."

   3. NIT: Also in the introduction: "[RFC4145] defines a mechanism,
      COMEDIA, which endpoints can use..." should read "[RFC4145]
      defines a mechanism, COMEDIA, that endpoints can use..." (the
      phrase at the end of the sentence isn't incidental to its meaning
      -- it is the purpose of the sentence).

   4. SUBSTANTIVE: I agree with earlier comments that the first
      paragraph of section 3 is a bit confusing, as it appears to impose
      a normative requirement on all MSRP UAs. Removal seems a bit of
      overkill, though, as it leaves implementors no information about
      when ACM should be employed.

      The second paragraph of section 3 talks about NAT traversal
      failures under certain circumstances, but provides implementors no
      guidance about how to avoid these failures. I think you need to
      add text that basically recommends that UA implementations that
      can be configured to use ACM as their NAT traversal strategy also
      MUST have the ability to use MSRP relays. (In other words:
      mandatory to implement, optional to use). Otherwise, you're
      encouraging deployment of clients that can perform NAT traversal,
      but only under fairly limited network circumstances.

   5. NIT: in section 4.2, "holdcon" should be spelled "holdconn" (two
      'n's).

   6. SUBSTANTIVE: In section 4.2, I think we need an explanation in the
      document regarding why "holdconn" is normatively prohibited. It's
      not immediately clear to me why we prevent this, and I can't find
      any discussion on the SIMPLE mailing list on the topic.

   7. SUBSTANTIVE: A natural consequence of the rules in section 4.2 is
      that an _offer_ for an MSRP session must never be "passive." To
      avoid misinterpretation, this should be stated as a normative
      requirement.

   8. SUBSTANTIVE: Unlike SIP, I don't think MSRP has rules that require
      recipients to ignore CRLF sequences in a TCP connection. I'm
      pretty sure that the CRLF mechanism described in section 5 for
      pinhole preservation is NOT backwards compatible. However, RFC
      4975 does talk about NAT binding keepalives in RFC 4975, section
      7.1: "Bodiless requests may also be used in certain applications
      to keep Network Address Translation (NAT) bindings alive, etc."

   9. SUBSTANTIVE: Also related to section 5: I'm certain that nothing
      in draft-ietf-mmusic-ice provides guidance here: that document
      deals with UDP, while MSRP is exclusively a TCP protocol. Perhaps
      you intended to cite draft-ietf-mmusic-ice-tcp?

==========
draft-ietf-simple-msrp-sessmatch

   1. NIT: The abstract contains several acronyms that need to be
      expanded (MSRP, UA, ALG) -- see section 3.6 of
      http://www.rfc-editor.org/rfc-style-guide/rfc-style

   2. NIT: The unexpanded acronym issue continues through the
      introduction: SLA, B2BUA, NAPT, ALG.

   3. SUBSTANTIVE: This document updates RFC 4975, section 7.1, which
      talks about ongoing sessions. However, to succeed, we also need to
      modify the matching procedure that takes place during session
      establishment. This is described in RFC 4975, section 5.4.

   4. SUBSTANTIVE: In the security section, we need to talk through the
      implications of this mechanism on TLS connections. After some
      cursory thought on the topic, I think it works correctly: outbound
      connections to MSRP relays will be okay, since the cert presented
      by the relay will match the hostname the client used to connect to
      it; and, for peer-to-peer mode (as described in RFC 4975, section
      14.4), the hostname isn't part of the information used to match
      the certificate. However, just because I think it works doesn't
      mean that it actually does. :) I'd be a lot more comfortable if we
      have a brief treatment of this issue in the security section so
      that it gets some explicit security review.

   5. NIT: Somewhere in the document, it would probably be good to cite
      the text from RFC 4975, section 14.1, regarding MSRP security
      properties: "Most components of the URI, such as the scheme and
      the authority components, are common knowledge.  The secrecy is
      entirely provided by the session-id component." This goes a long
      way towards allaying any concerns that the host portion was
      intended to provide any kind of protection when matching sessions.

/a

From ben@nostrum.com  Mon Dec 21 15:45:11 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54E23A6814 for ; Mon, 21 Dec 2009 15:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0MMbaAj3DFX for ; Mon, 21 Dec 2009 15:45:11 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 93E5E3A67B7 for ; Mon, 21 Dec 2009 15:45:10 -0800 (PST)
Received: from [10.0.1.8] (adsl-68-94-28-128.dsl.rcsntx.swbell.net [68.94.28.128]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nBLNiZ9u034861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Dec 2009 17:44:35 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Ben Campbell 
In-Reply-To: <4B30038C.7020308@estacado.net>
Date: Mon, 21 Dec 2009 17:44:30 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <93284A19-C7CD-4832-B1E4-CBE19C7351D2@nostrum.com>
References: <05FD3015-9D28-43CF-B44A-E14CBEB4E464@nostrum.com> <4B30038C.7020308@estacado.net>
To: Adam Roach 
X-Mailer: Apple Mail (2.1077)
Received-SPF: pass (nostrum.com: 68.94.28.128 is authenticated by a trusted mechanism)
Cc: Simple WG , draft-ietf-simple-msrp-acm@tools.ietf.org
Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2009 23:45:11 -0000

On Dec 21, 2009, at 5:23 PM, Adam Roach wrote:

> Just for clarification: the fact that we're last calling these at the =
same time doesn't mean that we intend them to progress as a cluster =
(http://www.rfc-editor.org/cluster_def.html), does it? There is no =
normative dependency between them, and I'd hate to see them both be =
delayed due to issues related to only one of them (e.g., in IETF last =
call, or IESG review).

I am not aware of any need for one of them to block the other. We will =
probably pubreq them together just because it may be easier for the IESG =
to interpret them together. But if we found a blocking problem with one =
draft, I don't see a need to delay the other.

If anyone feels this is in error, please let the chairs know asap.

Thanks!

Ben.=

From krisztian.kiss@nokia.com  Wed Dec 23 11:50:08 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FE03A686E for ; Wed, 23 Dec 2009 11:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XQWpVLECAhE for ; Wed, 23 Dec 2009 11:50:07 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7A01D3A6840 for ; Wed, 23 Dec 2009 11:50:07 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBNJnfXF004056; Wed, 23 Dec 2009 21:49:47 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 23 Dec 2009 21:44:04 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 23 Dec 2009 21:44:04 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 23 Dec 2009 20:44:03 +0100
From: 
To: , 
Date: Wed, 23 Dec 2009 20:44:01 +0100
Thread-Topic: Draft new versions: msrp-acm and sessmatch
Thread-Index: Acp/HYWJ2937C3iwRvOnVUmw7FgrMQE6fF2Q
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A80667440D58A1469E651BA443BED3C1503FA6AA2FNOKEUMSG01mgd_"
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Dec 2009 19:44:04.0916 (UTC) FILETIME=[48C81F40:01CA8408]
X-Nokia-AV: Clean
Subject: Re: [Simple] Draft new versions: msrp-acm and sessmatch
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2009 19:50:08 -0000

--_000_A80667440D58A1469E651BA443BED3C1503FA6AA2FNOKEUMSG01mgd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I read these documents and in my view they are ready to be published.

Cheers,
Krisztian

________________________________
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of=
 ext Christer Holmberg
Sent: Thursday, December 17, 2009 5:34 AM
To: simple@ietf.org
Subject: [Simple] Draft new versions: msrp-acm and sessmatch

Hi,

Based on the WGLC comments, I have submitted new versions of draft-ietf-sim=
ple-msrp-acm (-03) and draft-ietf-simple-msrp-sessmatch (-01).

The drafts can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-03.txt
http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-sessmatch-01.=
txt

Regards,

Christer

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

Hi,

I read these documents and in my view they are ready to be published.

Cheers,
Krisztian

From: simple-bounces@ietf.org=20
[mailto:simple-bounces@ietf.org] On Behalf Of ext Christer=20
Holmberg
Sent: Thursday, December 17, 2009 5:34 AM
To:=
=20
simple@ietf.org
Subject: [Simple] Draft new versions: msrp-acm an=
d=20
sessmatch

Hi,

Based on the WGLC comments, I have submitted new versio=
ns of=20
draft-ietf-simple-msrp-acm (-03) and draft-ietf-simple-msrp-sessmatch=20
(-01).

The drafts can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-simple=
-msrp-acm-03.txt
http://users.piuha.net/cholmber/drafts/draft-ietf-simple=
-msrp-sessmatch-01.txt

Regards,

Christer

--_000_A80667440D58A1469E651BA443BED3C1503FA6AA2FNOKEUMSG01mgd_--

From ibc@aliax.net  Sun Dec 27 14:47:58 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A743A6919 for ; Sun, 27 Dec 2009 14:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level: 
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syYeB1LN-Yxb for ; Sun, 27 Dec 2009 14:47:58 -0800 (PST)
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 698E63A687A for ; Sun, 27 Dec 2009 14:47:55 -0800 (PST)
Received: by fxm7 with SMTP id 7so9287595fxm.29 for ; Sun, 27 Dec 2009 14:47:32 -0800 (PST)
Received: by 10.223.6.196 with SMTP id a4mr280361faa.70.1261954052399; Sun, 27 Dec 2009 14:47:32 -0800 (PST)
Received: from ibc-laptop.localnet (16.85-84-188.dynamic.clientes.euskaltel.es [85.84.188.16]) by mx.google.com with ESMTPS id 15sm3823126fxm.2.2009.12.27.14.47.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Dec 2009 14:47:31 -0800 (PST)
From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= 
To: simple@ietf.org
Date: Sun, 27 Dec 2009 23:47:28 +0100
User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; )
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200912272347.28326.ibc@aliax.net>
Subject: [Simple] Subscription to XCAP document: which is the definitive draft?
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Dec 2009 22:47:58 -0000

Hi, my question is related to subscription for XCAP document changes:

a)
The format for XCAP diff is defined in:
  http://tools.ietf.org/html/draft-ietf-simple-xcap-diff

b)
How a SIP user agent subscribes to changes in XCAP documents is defined in:
  http://tools.ietf.org/html/draft-ietf-sip-xcapevent
However it's also defined in:
  http://tools.ietf.org/html/draft-ietf-sip-xcap-config  (page 8)

This last draft is an extension to draft-ietf-sipping-config-framework so a=
=20
device can get its provisioned configuration from a XCAP resource. But it a=
lso=20
allows a SIP user to subscribe to changes in XCAP documents.

So, which is the definitive way?

Thanks a lot.

=2D-=20
I=C3=B1aki Baz Castillo 

From ibc@aliax.net  Sun Dec 27 15:36:43 2009
Return-Path: 
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2955C3A682E for ; Sun, 27 Dec 2009 15:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.07
X-Spam-Level: 
X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_20=-0.74, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc8--5dNmcDs for ; Sun, 27 Dec 2009 15:36:42 -0800 (PST)
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 1D48B3A6817 for ; Sun, 27 Dec 2009 15:36:41 -0800 (PST)
Received: by fxm7 with SMTP id 7so9301674fxm.29 for ; Sun, 27 Dec 2009 15:36:19 -0800 (PST)
Received: by 10.223.161.212 with SMTP id s20mr5728780fax.2.1261956979290; Sun, 27 Dec 2009 15:36:19 -0800 (PST)
Received: from ibc-laptop.localnet (16.85-84-188.dynamic.clientes.euskaltel.es [85.84.188.16]) by mx.google.com with ESMTPS id 16sm3818025fxm.4.2009.12.27.15.36.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Dec 2009 15:36:18 -0800 (PST)
From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= 
To: simple@ietf.org
Date: Mon, 28 Dec 2009 00:36:15 +0100
User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; )
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200912280036.15514.ibc@aliax.net>
Subject: [Simple] SUBSCRIBE for xcap-diff event sent by the presence server to the XCAP server
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Dec 2009 23:36:43 -0000

Hi, the way a presence server receives notifications for changes in XCAP=20
documents (so it can notify the watchers) is by subscribing to the XCAP ser=
ver=20
for the event "xcap-diff" as specified in:
  http://tools.ietf.org/html/draft-ietf-sip-xcapevent

I would like to understand how such SUBSCRIBE sent by the presence server=20
looks. The above draft just shows examples when a SIP user send such SUBSCR=
IBE=20
but no one example when the subscriber is the presence server.

=46or example, let's imagine a simplified case in which there are just two =
XCAP=20
applications ("pres-rules" and "resource-lists").

The presence server should subscribe to users documents. AFAIK the presence=
=20
server would send a SUBSCRIBE as follows:

   SUBSCRIBE sip:xcap-server@domain.org SIP/2.0
   From: sip:presence-server@domain.org
   Accept: application/xcap-diff+xml
   Event: xcap-diff; diff-processing=3Dno-patching
   Content-Type: application/resource-lists+xml

Then when any user creates or modifies a XCAP document for those auids, the=
n=20
XCAP server would sent a NOTIFY to the presence-server telling the document=
=20
addition/modification.

Doubts:

=2D Is the above correct? (is it defined somewhere?)

=2D Most probably the presence-server is just interested in "index" documen=
ts=20
for both XCAP applications. However it would receive notifications for ever=
y=20
document created by any user even if it's not called "index". Is it the=20
expected behavior? How to ask in the SUBSCRIBE that there is noly interest =
on=20
"index" called documents?

=2D Could the notification from the XCAP server to the presence server work=
 with=20
PUBLISH rather than SUBSCRIBE & NOTIFY? This is: when a XCAP document is=20
modified the XCAP server sends a PUBLISH to the presence server with xcap-d=
iff=20
body. Does it make sense?

=2D And last question. Are all my questions defined in IETF docs? or do the=
y=20
require specifications on top of IETF docs as OMA specs?

Thanks a lot and best regards.

By sending the above XML body the=20

=2D-=20
I=C3=B1aki Baz Castillo 