From davecruse1@hotmail.com Tue May 1 00:59:44 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D321F8663 for ; Tue, 1 May 2012 00:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5MR6B3N51vE for ; Tue, 1 May 2012 00:59:43 -0700 (PDT) Received: from blu0-omc3-s7.blu0.hotmail.com (blu0-omc3-s7.blu0.hotmail.com [65.55.116.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33521F8661 for ; Tue, 1 May 2012 00:59:36 -0700 (PDT) Received: from BLU161-W3 ([65.55.116.74]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 00:59:35 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6aca84c4-852d-42cb-8afc-b0c673e03700_" X-Originating-IP: [72.163.217.103] From: dave Cruse To: , , Date: Tue, 1 May 2012 07:59:35 +0000 Importance: Normal In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC3C4F@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C01DAE0D9@inba-mail01.sonusnet.com>, <35BCE99A477D6A4986FB2216D8CF2CFD08F27E22@XMB-BGL-417.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DC3C4F@inba-mail01.sonusnet.com> MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2012 07:59:35.0569 (UTC) FILETIME=[598AA010:01CD2770] Subject: Re: [dispatch] SIP media load balancer requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 07:59:44 -0000 --_6aca84c4-852d-42cb-8afc-b0c673e03700_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C I have few basic queries on this draft. How does SIP Load balancer shift traffic from one path to another to avoid = congestion on any particular=20 link? How does Load balancer minimize the cost of transit across external network= s OR improve network=20 reliability? How is your SIP Load balancer used to implement failover of one or more of = its components? Does your=20 components are monitored continually? How does SIP load balancer is used to monitor network activities and can it= be used to split huge data=20 flows into several sub-flows and use several network analyzers? How can you achieve SIP based load balancing for media servers like PSTN-SI= P GW=2C SBC=2CvOICE Gateway etc. Regards - Dave > From: pravindran@sonusnet.com > To: rmohanr@cisco.com=3B dispatch@ietf.org > Date: Thu=2C 5 Jan 2012 06:28:22 +0000 > Subject: Re: [dispatch] SIP media load balancer requirement >=20 > Hi Ram=2C >=20 > Nice to see your interest. Please read inline for more comments. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >Sent: Thursday=2C January 05=2C 2012 11:45 AM > >To: Ravindran=2C Parthasarathi=3B dispatch@ietf.org > >Subject: RE: [dispatch] SIP media load balancer requirement > > > >Hi Partha=2C > > > >I would be interested in this work. See more inline > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Ravindran=2C Parthasarathi > >> Sent: Thursday=2C December 22=2C 2011 8:02 AM > >> To: dispatch@ietf.org > >> Subject: [dispatch] SIP media load balancer requirement > >> > >> Hi all=2C > >> > >> As a continuation of IETF-81 Dispatch minutes > >> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03742.html) > >> about SIP load balancing=2C I thought of discussing about SIP media > >> servers load balancing as mentioned in the SIP load balancing proposed > >> charter (http://www.ietf.org/mail- > >> archive/web/dispatch/current/msg03615.html). > >> > >> "As SIP request resource consumption in SIP signaling only server > >> varies drastically from SIP media servers [3]=2C should the solution b= e > >> split such that load balancing of a pure signaling server is different > >> than that of a SIP server that handles signaling as well as media?" > >> > >> SIP media server load balancing solution will be different from > >> signaling only because the downstream resource consumption is mainly > >> because of media (RTP) than signaling (SIP) and the units to indicate > >> the load balancing information will be different in both solution. > >> There is a need to indicate those media resource consumption to the > >> load balancer in the standard manner. Please let me know your comment > >> on this. > > > >I think what we need is some text/document saying how media overload is > >different from signaling overload and what are the different resources > >that need to considered for media overload. In that way we will have > >good starting point to discuss on this topic. >=20 > The focus of this charter is about SIP media load balancing and = not media overload handling. I agree with you that SIP media load balancing= algorithm works in conjunction with media overload mechanism and selection= of the load balancing algorithm majorly depends upon media overload mechan= ism.=20 >=20 > SIP media load balancer requirement is to consider media resource consump= tion of the peer apart from the signaling resource consumption. >=20 > > > >Regards=2C > >Ram > >> > >> Thanks > >> Partha > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --_6aca84c4-852d-42cb-8afc-b0c673e03700_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello=2C

I have few basic queries on this draft.


How = does SIP Load balancer shift traffic from one path to another to avoid cong= estion on any particular

link?

How does Load balancer minimi= ze the cost of transit across external networks OR improve network

= reliability?

How is your SIP Load balancer used to implement failove= r of one or more of its components? Does your

components are monito= red continually?

How does SIP load balancer is used to monitor netwo= rk activities and can it be used to split huge data

flows into seve= ral sub-flows and use several network analyzers?

How can you achieve= SIP based load balancing for media servers like PSTN-SIP GW=2C SBC=2CvOICE= Gateway etc.

Regards
- Dave

>=3B From: pravindran@sonusnet.com
>=3B To: rmohanr@ci= sco.com=3B dispatch@ietf.org
>=3B Date: Thu=2C 5 Jan 2012 06:28:22 +00= 00
>=3B Subject: Re: [dispatch] SIP media load balancer requirement>=3B
>=3B Hi Ram=2C
>=3B
>=3B Nice to see your interest= . Please read inline for more comments.
>=3B
>=3B Thanks
>= =3B Partha
>=3B
>=3B >=3B-----Original Message-----
>=3B = >=3BFrom: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
>=3B >= =3BSent: Thursday=2C January 05=2C 2012 11:45 AM
>=3B >=3BTo: Ravind= ran=2C Parthasarathi=3B dispatch@ietf.org
>=3B >=3BSubject: RE: [dis= patch] SIP media load balancer requirement
>=3B >=3B
>=3B >= =3BHi Partha=2C
>=3B >=3B
>=3B >=3BI would be interested in t= his work. See more inline
>=3B >=3B
>=3B >=3B>=3B -----Orig= inal Message-----
>=3B >=3B>=3B From: dispatch-bounces@ietf.org [m= ailto:dispatch-bounces@ietf.org] On
>=3B >=3B>=3B Behalf Of Ravind= ran=2C Parthasarathi
>=3B >=3B>=3B Sent: Thursday=2C December 22= =2C 2011 8:02 AM
>=3B >=3B>=3B To: dispatch@ietf.org
>=3B >= =3B>=3B Subject: [dispatch] SIP media load balancer requirement
>=3B= >=3B>=3B
>=3B >=3B>=3B Hi all=2C
>=3B >=3B>=3B
&g= t=3B >=3B>=3B As a continuation of IETF-81 Dispatch minutes
>=3B &= gt=3B>=3B (http://www.ietf.org/mail-archive/web/dispatch/current/msg03742= .html)
>=3B >=3B>=3B about SIP load balancing=2C I thought of disc= ussing about SIP media
>=3B >=3B>=3B servers load balancing as men= tioned in the SIP load balancing proposed
>=3B >=3B>=3B charter (h= ttp://www.ietf.org/mail-
>=3B >=3B>=3B archive/web/dispatch/curren= t/msg03615.html).
>=3B >=3B>=3B
>=3B >=3B>=3B "As SIP req= uest resource consumption in SIP signaling only server
>=3B >=3B>= =3B varies drastically from SIP media servers [3]=2C should the solution be=
>=3B >=3B>=3B split such that load balancing of a pure signaling = server is different
>=3B >=3B>=3B than that of a SIP server that h= andles signaling as well as media?"
>=3B >=3B>=3B
>=3B >=3B= >=3B SIP media server load balancing solution will be different from
&= gt=3B >=3B>=3B signaling only because the downstream resource consumpti= on is mainly
>=3B >=3B>=3B because of media (RTP) than signaling = (SIP) and the units to indicate
>=3B >=3B>=3B the load balancing i= nformation will be different in both solution.
>=3B >=3B>=3B There= is a need to indicate those media resource consumption to the
>=3B &g= t=3B>=3B load balancer in the standard manner. Please let me know your co= mment
>=3B >=3B>=3B on this.
>=3B >=3B
>=3B >=3BI th= ink what we need is some text/document saying how media overload is
>= =3B >=3Bdifferent from signaling overload and what are the different reso= urces
>=3B >=3Bthat need to considered for media overload. In that w= ay we will have
>=3B >=3Bgood starting point to discuss on this topi= c.
>=3B
>=3B <=3Bpartha>=3B The focus of this charter is abo= ut SIP media load balancing and not media overload handling. I agree with y= ou that SIP media load balancing algorithm works in conjunction with media = overload mechanism and selection of the load balancing algorithm majorly de= pends upon media overload mechanism.
>=3B
>=3B SIP media load b= alancer requirement is to consider media resource consumption of the peer a= part from the signaling resource consumption. <=3B/partha>=3B
>= =3B
>=3B >=3B
>=3B >=3BRegards=2C
>=3B >=3BRam
>= =3B >=3B>=3B
>=3B >=3B>=3B Thanks
>=3B >=3B>=3B Parth= a
>=3B >=3B>=3B _______________________________________________>=3B >=3B>=3B dispatch mailing list
>=3B >=3B>=3B dispatch@= ietf.org
>=3B >=3B>=3B https://www.ietf.org/mailman/listinfo/dispa= tch
>=3B _______________________________________________
>=3B dis= patch mailing list
>=3B dispatch@ietf.org
>=3B https://www.ietf.o= rg/mailman/listinfo/dispatch
= --_6aca84c4-852d-42cb-8afc-b0c673e03700_-- From pravindran@sonusnet.com Wed May 2 05:18:56 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529DF21F89BD for ; Wed, 2 May 2012 05:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 890NHgvOTejP for ; Wed, 2 May 2012 05:18:55 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 81F7E21F89BA for ; Wed, 2 May 2012 05:18:54 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT6EmLYzRTUu/ZmVwMCYIE6zWSzxIR1Mj@postini.com; Wed, 02 May 2012 05:18:54 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 2 May 2012 08:18:59 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 2 May 2012 17:48:49 +0530 From: "Ravindran, Parthasarathi" To: dave Cruse , "rmohanr@cisco.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP media load balancer requirement Thread-Index: AczAUbSbDDcFGmmuRPiqlrieYjsdqQLDziqAAARMF+AW9Ah3gABGgIDA Date: Wed, 2 May 2012 12:18:48 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C14894528@inba-mail02.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C01DAE0D9@inba-mail01.sonusnet.com>, <35BCE99A477D6A4986FB2216D8CF2CFD08F27E22@XMB-BGL-417.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DC3C4F@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C14894528inbamail02sonus_" MIME-Version: 1.0 Subject: Re: [dispatch] SIP media load balancer requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 12:18:56 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C14894528inbamail02sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, Sec 3.5 of draft-partha-dispatch-siploadbalancing-survey-00 provides the ex= isting mechanism for SIP media load balancing. One of the solution is draf= t-partha-soc-overload-resource-availability-00 but the downside is that= of defining the units like CPU, Memory, DSP channels. Please read inline for more comments. Thanks Partha From: dave Cruse [mailto:davecruse1@hotmail.com] Sent: Tuesday, May 01, 2012 1:30 PM To: Ravindran, Parthasarathi; rmohanr@cisco.com; dispatch@ietf.org Subject: RE: [dispatch] SIP media load balancer requirement Hello, I have few basic queries on this draft. How does SIP Load balancer shift traffic from one path to another to avoid = congestion on any particular link? Shifting the traffic will be based on the feedback from the media = server and the local Policy How does Load balancer minimize the cost of transit across external network= s OR improve network reliability? I could not understand in detail. Could you please explain in deta= il here How is your SIP Load balancer used to implement failover of one or more of = its components? Does your components are monitored continually? Basically, there is a need of feedback mechanism. The failover cou= ld be 503 or threshold Limit reaching in the feedback. How does SIP load balancer is used to monitor network activities and can it= be used to split huge data flows into several sub-flows and use several network analyzers? In case of audio call, flow is mainly Based on SIP signaling and R= TP data with the negotiated codec. Please explain the actual huge data flow and its subflow.= How can you achieve SIP based load balancing for media servers like PSTN-SI= P GW, SBC,vOICE Gateway etc. One of the mechanism is mentioned in http://tools.ietf.org/html/dr= aft-partha-soc-overload-resource-availability-00 Regards - Dave > From: pravindran@sonusnet.com > To: rmohanr@cisco.com; dispatch@ietf.org > Date: Thu, 5 Jan 2012 06:28:22 +0000 > Subject: Re: [dispatch] SIP media load balancer requirement > > Hi Ram, > > Nice to see your interest. Please read inline for more comments. > > Thanks > Partha > > >-----Original Message----- > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >Sent: Thursday, January 05, 2012 11:45 AM > >To: Ravindran, Parthasarathi; dispatch@ietf.org > >Subject: RE: [dispatch] SIP media load balancer requirement > > > >Hi Partha, > > > >I would be interested in this work. See more inline > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mai= lto:dispatch-bounces@ietf.org] On > >> Behalf Of Ravindran, Parthasarathi > >> Sent: Thursday, December 22, 2011 8:02 AM > >> To: dispatch@ietf.org > >> Subject: [dispatch] SIP media load balancer requirement > >> > >> Hi all, > >> > >> As a continuation of IETF-81 Dispatch minutes > >> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03742.html) > >> about SIP load balancing, I thought of discussing about SIP media > >> servers load balancing as mentioned in the SIP load balancing proposed > >> charter (http://www.ietf.org/mail- > >> archive/web/dispatch/current/msg03615.html). > >> > >> "As SIP request resource consumption in SIP signaling only server > >> varies drastically from SIP media servers [3], should the solution be > >> split such that load balancing of a pure signaling server is different > >> than that of a SIP server that handles signaling as well as media?" > >> > >> SIP media server load balancing solution will be different from > >> signaling only because the downstream resource consumption is mainly > >> because of media (RTP) than signaling (SIP) and the units to indicate > >> the load balancing information will be different in both solution. > >> There is a need to indicate those media resource consumption to the > >> load balancer in the standard manner. Please let me know your comment > >> on this. > > > >I think what we need is some text/document saying how media overload is > >different from signaling overload and what are the different resources > >that need to considered for media overload. In that way we will have > >good starting point to discuss on this topic. > > The focus of this charter is about SIP media load balancing and = not media overload handling. I agree with you that SIP media load balancing= algorithm works in conjunction with media overload mechanism and selection= of the load balancing algorithm majorly depends upon media overload mechan= ism. > > SIP media load balancer requirement is to consider media resource consump= tion of the peer apart from the signaling resource consumption. > > > > >Regards, > >Ram > >> > >> Thanks > >> Partha > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --_000_387F9047F55E8C42850AD6B3A7A03C6C14894528inbamail02sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 <= /p>

Sec 3.5 of draft-partha-d= ispatch-siploadbalancing-survey-00 provides the existing mechanism for &nbs= p;SIP media load balancing. One of the solution is draft-partha-soc-overloa= d-resource-availability-00 but the downside is that of defining = the units like CPU, Memory, DSP channels.

 <= /p>

Please read inline for mo= re comments.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: dave Cru= se [mailto:davecruse1@hotmail.com]
Sent: Tuesday, May 01, 2012 1:30 PM
To: Ravindran, Parthasarathi; rmohanr@cisco.com; dispatch@ietf.org Subject: RE: [dispatch] SIP media load balancer requirement

 


Hello,

I have few basic queries on this draft.


How does SIP Load balancer shift traffic from one path to another to avoid = congestion on any particular

link?

<partha> Shifting the traffic will be based on the feedback fro= m the media server and the local

Policy </partha>


How does Load balancer minimize the cost of transit across external network= s OR improve network

reliability?

<partha> I could not understand in detail. Could you please exp= lain in detail here </partha>


How is your SIP Load balancer used to implement failover of one or more of = its components? Does your

components are monitored continually?

<partha> Basically, there is a need of feedback mechanism. The = failover could be 503 or threshold

Limit reaching in the feedback. </partha>


How does SIP load balancer is used to monitor network activities and can it= be used to split huge data

flows into several sub-flows and use several network analyzers?

<partha> In case of audio call, flow is mainly Based on SIP sig= naling and RTP data with the

negotiated codec. Please explain the actual huge data flow and its su= bflow.  </partha>


How can you achieve SIP based load balancing for media servers like PSTN-SI= P GW, SBC,vOICE Gateway etc.

<partha> One of the mechanism is mentioned in http://tools.ietf.org/html/draft-partha-soc-overload-resource-availability-= 00 </partha>



Regards
- Dave

> From: pravindran@sonusnet.com
> To: rmohanr@cisco.com; dispatch@ietf.org
> Date: Thu, 5 Jan 2012 06:28:22 +0000
> Subject: Re: [dispatch] SIP media load balancer requirement
>
> Hi Ram,
>
> Nice to see your interest. Please read inline for more comments.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [= mailto:rmohanr@cisco.com]
> >Sent: Thursday, January 05, 2012 11:45 AM
> >To: Ravindran, Parthasarathi; dispatch@ietf.org
> >Subject: RE: [dispatch] SIP media load balancer requirement
> >
> >Hi Partha,
> >
> >I would be interested in this work. See more inline
> >
> >> -----Original Message-----
> >> From: dispatch-b= ounces@ietf.org [mailto:di= spatch-bounces@ietf.org] On
> >> Behalf Of Ravindran, Parthasarathi
> >> Sent: Thursday, December 22, 2011 8:02 AM
> >> To: dispatch@ietf.org
> >> Subject: [dispatch] SIP media load balancer requirement
> >>
> >> Hi all,
> >>
> >> As a continuation of IETF-81 Dispatch minutes
> >> (http://www.ietf.org/mail-archive/web/dispatch/current/m= sg03742.html)
> >> about SIP load balancing, I thought of discussing about SIP m= edia
> >> servers load balancing as mentioned in the SIP load balancing= proposed
> >> charter (http://www.iet= f.org/mail-
> >> archive/web/dispatch/current/msg03615.html).
> >>
> >> "As SIP request resource consumption in SIP signaling on= ly server
> >> varies drastically from SIP media servers [3], should the sol= ution be
> >> split such that load balancing of a pure signaling server is = different
> >> than that of a SIP server that handles signaling as well as m= edia?"
> >>
> >> SIP media server load balancing solution will be different fr= om
> >> signaling only because the downstream resource consumption is= mainly
> >> because of media (RTP) than signaling (SIP) and the units to = indicate
> >> the load balancing information will be different in both solu= tion.
> >> There is a need to indicate those media resource consumption = to the
> >> load balancer in the standard manner. Please let me know your= comment
> >> on this.
> >
> >I think what we need is some text/document saying how media overlo= ad is
> >different from signaling overload and what are the different resou= rces
> >that need to considered for media overload. In that way we will ha= ve
> >good starting point to discuss on this topic.
>
> <partha> The focus of this charter is about SIP media load balan= cing and not media overload handling. I agree with you that SIP media load = balancing algorithm works in conjunction with media overload mechanism and = selection of the load balancing algorithm majorly depends upon media overload mechanism.
>
> SIP media load balancer requirement is to consider media resource cons= umption of the peer apart from the signaling resource consumption. </par= tha>
>
> >
> >Regards,
> >Ram
> >>
> >> Thanks
> >> Partha
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org > >> ht= tps://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch

--_000_387F9047F55E8C42850AD6B3A7A03C6C14894528inbamail02sonus_-- From davecruse1@hotmail.com Thu May 3 06:51:00 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9491021F847B for ; Thu, 3 May 2012 06:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSYXGz3+SdCG for ; Thu, 3 May 2012 06:51:00 -0700 (PDT) Received: from blu0-omc4-s11.blu0.hotmail.com (blu0-omc4-s11.blu0.hotmail.com [65.55.111.150]) by ietfa.amsl.com (Postfix) with ESMTP id 09D0621F8473 for ; Thu, 3 May 2012 06:50:59 -0700 (PDT) Received: from BLU161-W27 ([65.55.111.135]) by blu0-omc4-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 06:50:59 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a645e68b-2307-4853-a883-bc47a1468f57_" X-Originating-IP: [72.163.217.105] From: dave Cruse To: Date: Thu, 3 May 2012 13:50:58 +0000 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2012 13:50:59.0150 (UTC) FILETIME=[C52946E0:01CD2933] Subject: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 13:51:00 -0000 --_a645e68b-2307-4853-a883-bc47a1468f57_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Glen=2C I have some few basic questions here: Q1. Does this feature support TLS UDP OR just TCP only? Q2. What if Endpoint support only FAX but not Video? Regards - Dave > Date: Mon=2C 5 Mar 2012 13:36:52 -0800 > From: glavers@cisco.com > To: sipcore@ietf.org > CC: paulej@packetizer.com=3B gsalguei@cisco.com > Subject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt >=20 > Folks=2C > I have submitted a new draft to define an 'immersive' media feature tag. = The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-imm= ersive-capability=20 >=20 > The authors would appreciate feedback and or detailed comments.=20 >=20 > Many thanks=2C > Glen=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --_a645e68b-2307-4853-a883-bc47a1468f57_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


=


Hello Glen=2C

I have some few basic questions here:

Q1. D= oes this feature support TLS UDP OR just TCP only?


Q2. What if E= ndpoint support only FAX but not Video?

Regards
- Dave

>=3B Date: Mon=2C 5 Mar 2012 1= 3:36:52 -0800
>=3B From: glavers@cisco.com
>=3B To: sipcore@ietf.= org
>=3B CC: paulej@packetizer.com=3B gsalguei@cisco.com
>=3B Sub= ject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt
>=3B =
>=3B Folks=2C
>=3B I have submitted a new draft to define an 'im= mersive' media feature tag. The draft is posted at: http://tools.ietf.org/h= tml/draft-lavers-sipcore-immersive-capability
>=3B
>=3B The aut= hors would appreciate feedback and or detailed comments.
>=3B
&g= t=3B Many thanks=2C
>=3B Glen
>=3B _____________________________= __________________
>=3B sipcore mailing list
>=3B sipcore@ietf.or= g
>=3B https://www.ietf.org/mailman/listinfo/sipcore
=
= --_a645e68b-2307-4853-a883-bc47a1468f57_-- From dworley@avaya.com Thu May 3 07:37:18 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3A21F8610 for ; Thu, 3 May 2012 07:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw2d2naQm1BL for ; Thu, 3 May 2012 07:37:18 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A021821F8606 for ; Thu, 3 May 2012 07:37:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAFAKCWok/GmAcF/2dsb2JhbABEoE+SJ4EHggkBAQEBAgESKEQLAgEIDQghEDIcCQEBBAESCBqHXQMGBZ0knSaKBoYfYwSUJodwhSeFA4ME X-IronPort-AV: E=Sophos;i="4.75,524,1330923600"; d="scan'208";a="7386759" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 May 2012 10:37:14 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 May 2012 10:33:16 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 3 May 2012 10:36:14 -0400 From: "Worley, Dale R (Dale)" To: dave Cruse , "dispatch@ietf.org" Date: Thu, 3 May 2012 10:35:09 -0400 Thread-Topic: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Ac0pM8igIv4fXcUHREeU0SF3CrgzfgABih4X 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:37:18 -0000 > From: dave Cruse [davecruse1@hotmail.com] >=20 > I have some few basic questions here: > [...] > Q2. What if Endpoint support only FAX but not Video? I'm curious what the definition of "immersive fax" would be... Dale From davecruse1@hotmail.com Thu May 3 08:17:58 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7568421F85D7 for ; Thu, 3 May 2012 08:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0uMYa662H9y for ; Thu, 3 May 2012 08:17:57 -0700 (PDT) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id 9504121F85C2 for ; Thu, 3 May 2012 08:17:57 -0700 (PDT) Received: from BLU161-W65 ([65.55.116.72]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 08:17:56 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b92bd6cd-2b34-4c93-97da-2589051cf5bb_" X-Originating-IP: [72.163.217.105] From: dave Cruse To: Date: Thu, 3 May 2012 15:17:56 +0000 Importance: Normal In-Reply-To: References: <4761bf7d-c7b6-407e-a9da-bbdd892396e1@ietf.org>, , , , MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2012 15:17:56.0959 (UTC) FILETIME=[EB37BEF0:01CD293F] Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dispatch-sip-continuation-option-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:17:58 -0000 --_b92bd6cd-2b34-4c93-97da-2589051cf5bb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Manjunath=2C=20 Here in working group I see few email conversationsabout NDDND continuatio= n etc what is that you want to convey aboutyour proprietary NDDND mechansim= ? Could you explain your NDDND and call-continuation feature with flow diagram and how are you going toimpleme= nt this? What is the difference between DND and NDDNDmechansim approach? - Dave > From: dworley@avaya.com > To: manjugd@gmail.com > Date: Mon=2C 23 Apr 2012 11:54:59 -0400 > CC: dispatch@ietf.org > Subject: Re: [dispatch] Fwd: New Version Notification for draft-sinha-dis= patch-sip-continuation-option-03.txt >=20 > > From: Manjunath [manjugd@gmail.com] > >=20 > > > As far as I can tell=2C you place great emphasis on the need for the > > > callee to communicate his state to the caller. And that this is the > > > reason that the "Priority" header in the INVITE is not a sufficient > > > solution. > > [...] > > > This is not specified in a requirement in Amardeep's list of > > > requirements. > >=20 > > [Manjunath] :What Amardeep sent earlier was just the consolidated > > requirement list. >=20 > However you should ensure that the consolidated requirement list > contains this requirement=2C as it is an essential reason for organizing > the "continuation" mechanism in the way you have organized it. >=20 > > > But I do not know of a justification that it is important for the > > > callee to communicate his state to the caller. The caller knows > > > before placing the call whether it is important enough to interrupt > > > the callee. Knowing whether the callee is busy does not change that. > >=20 > > [Manjunath] : Yes it would be important for the callee to communicate > > his state to the caller because that particular call at that moment > > may not be important for callee. > >=20 > > Yes=2C the caller knows before placing the call whether it is important > > enough to interrupt the callee. And knowing whether the calee is busy > > (DND set) the caller will not change his/her state. That means caller > > wants callee to answer his/her URGENT call. And this is only possible > > when callee notice the alert OR pop-up message or light blink. If > > callee missed OR unnoticed pop-up message OR light blink then callee > > will not answer the caller=92s URGENT call even though the caller has > > sent the request with High priority. So if callee sets NDDND (as > > defined in draft) we can overcome this problem. >=20 > However=2C since we are considering changing the callee's phone's > behavior already=2C why not modify the callee's phone to ring when it > receives an INVITE with "Priority: urgent" even if the phone is busy > or has DND set? >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --_b92bd6cd-2b34-4c93-97da-2589051cf5bb_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Manjunath=2C

Here in working group I see few  =3Bema= il conversations
about NDDND continuation etc what is that you wa= nt to convey about
your proprietary NDDND mechansim? Could you ex= plain your  =3BNDDND and
call-continuation feature with flow diagram and how are you going to
implement this? What is the difference  =3Bbetween DND and NDD= ND
mechansim approach?


- Dave

>=3B From: dworley@avaya.com
>=3B To: ma= njugd@gmail.com
>=3B Date: Mon=2C 23 Apr 2012 11:54:59 -0400
>=3B= CC: dispatch@ietf.org
>=3B Subject: Re: [dispatch] Fwd: New Version N= otification for draft-sinha-dispatch-sip-continuation-option-03.txt
>= =3B
>=3B >=3B From: Manjunath [manjugd@gmail.com]
>=3B >=3B =
>=3B >=3B >=3B As far as I can tell=2C you place great emphasis o= n the need for the
>=3B >=3B >=3B callee to communicate his state = to the caller. And that this is the
>=3B >=3B >=3B reason that th= e "Priority" header in the INVITE is not a sufficient
>=3B >=3B >= =3B solution.
>=3B >=3B [...]
>=3B >=3B >=3B This is not sp= ecified in a requirement in Amardeep's list of
>=3B >=3B >=3B requ= irements.
>=3B >=3B
>=3B >=3B [Manjunath] :What Amardeep sen= t earlier was just the consolidated
>=3B >=3B requirement list.
&= gt=3B
>=3B However you should ensure that the consolidated requiremen= t list
>=3B contains this requirement=2C as it is an essential reason = for organizing
>=3B the "continuation" mechanism in the way you have o= rganized it.
>=3B
>=3B >=3B >=3B But I do not know of a just= ification that it is important for the
>=3B >=3B >=3B callee to co= mmunicate his state to the caller. The caller knows
>=3B >=3B >= =3B before placing the call whether it is important enough to interrupt
= >=3B >=3B >=3B the callee. Knowing whether the callee is busy does n= ot change that.
>=3B >=3B
>=3B >=3B [Manjunath] : Yes it wou= ld be important for the callee to communicate
>=3B >=3B his state to= the caller because that particular call at that moment
>=3B >=3B ma= y not be important for callee.
>=3B >=3B
>=3B >=3B Yes=2C th= e caller knows before placing the call whether it is important
>=3B &g= t=3B enough to interrupt the callee. And knowing whether the calee is busy<= br>>=3B >=3B (DND set) the caller will not change his/her state. That m= eans caller
>=3B >=3B wants callee to answer his/her URGENT call. An= d this is only possible
>=3B >=3B when callee notice the alert OR po= p-up message or light blink. If
>=3B >=3B callee missed OR unnoticed= pop-up message OR light blink then callee
>=3B >=3B will not answer= the caller=92s URGENT call even though the caller has
>=3B >=3B sen= t the request with High priority. So if callee sets NDDND (as
>=3B >= =3B defined in draft) we can overcome this problem.
>=3B
>=3B Ho= wever=2C since we are considering changing the callee's phone's
>=3B b= ehavior already=2C why not modify the callee's phone to ring when it
>= =3B receives an INVITE with "Priority: urgent" even if the phone is busy>=3B or has DND set?
>=3B
>=3B Dale
>=3B _______________= ________________________________
>=3B dispatch mailing list
>=3B = dispatch@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/dispatch<= br>
= --_b92bd6cd-2b34-4c93-97da-2589051cf5bb_-- From paulej@packetizer.com Fri May 4 01:51:20 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3306B21F8533 for ; Fri, 4 May 2012 01:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2h+9n6Ejncr for ; Fri, 4 May 2012 01:51:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 23D8621F8496 for ; Fri, 4 May 2012 01:51:19 -0700 (PDT) Received: from [156.106.218.124] ([156.106.218.124]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q448pBPB017110 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 May 2012 04:51:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336121476; bh=hQQ52I5sbFyksLQS7GkATXWjJI4hbjJ9iiVs6iMdgxA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Cd9PpcVX6a56viUkLPtddF93ihITVYsfLmKPVh+T/vR/aaJhZWNIkHGjq91xvzGvT yJtFoDUhUzZp3vrx5j36v1Cf9tR+zyyJuuZRzXnBYEGEt5GXXdteeEDKRTb2e7o911 xPFCn7HUJqbm2sMtTXGDqKUqs3TjuHdT0M15Yn+4= Message-ID: <4FA39884.1020304@packetizer.com> Date: Fri, 04 May 2012 04:51:16 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 08:51:20 -0000 I can't imagine why somebody would advertise that their fax device is "immersive", but there would be no harm if they did. If the fax-only device also advertised video, that would be a problem. The "immersive" feature was intended only to direct calls to devices labeled as such in an effort to help ensure that if A calls B asking for "immersive", then there is some reasonable chance that, if B had an immersive device, the call would get routed to the right one. Paul On 5/3/2012 10:35 AM, Worley, Dale R (Dale) wrote: >> From: dave Cruse [davecruse1@hotmail.com] >> >> I have some few basic questions here: >> [...] >> Q2. What if Endpoint support only FAX but not Video? > I'm curious what the definition of "immersive fax" would be... > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Fri May 4 07:18:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A434A21F8622 for ; Fri, 4 May 2012 07:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmlaxxBu5cdF for ; Fri, 4 May 2012 07:18:28 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 00CEE21F8620 for ; Fri, 4 May 2012 07:18:27 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta07.westchester.pa.mail.comcast.net with comcast id 5pPc1j0080EZKEL57qJLGP; Fri, 04 May 2012 14:18:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id 5qJY1j00d07duvL3MqJYAc; Fri, 04 May 2012 14:18:32 +0000 Message-ID: <4FA3E533.7070308@alum.mit.edu> Date: Fri, 04 May 2012 10:18:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: , , <4FA39884.1020304@packetizer.com> In-Reply-To: <4FA39884.1020304@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:18:28 -0000 On 5/4/12 4:51 AM, Paul E. Jones wrote: > I can't imagine why somebody would advertise that their fax device is > "immersive", but there would be no harm if they did. If the fax-only > device also advertised video, that would be a problem. If somebody advertised their fax-only device as immersive, then either they made a mistake, or they have a different notion of what immersive means than I do. But lacking a firm definition of immersive I guess they could choose whatever meaning they want. But this then comes back to the fundamental issue - that we need the caller and the callee to have a common understanding of what this means. Thanks, Paul > The "immersive" feature was intended only to direct calls to devices > labeled as such in an effort to help ensure that if A calls B asking for > "immersive", then there is some reasonable chance that, if B had an > immersive device, the call would get routed to the right one. > > Paul > > On 5/3/2012 10:35 AM, Worley, Dale R (Dale) wrote: >>> From: dave Cruse [davecruse1@hotmail.com] >>> >>> I have some few basic questions here: >>> [...] >>> Q2. What if Endpoint support only FAX but not Video? >> I'm curious what the definition of "immersive fax" would be... >> >> Dale >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From keith.drage@alcatel-lucent.com Fri May 4 08:38:33 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1A021E801A for ; Fri, 4 May 2012 08:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.826 X-Spam-Level: X-Spam-Status: No, score=-109.826 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbDt0dXnLJHG for ; Fri, 4 May 2012 08:38:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 813E321E8013 for ; Fri, 4 May 2012 08:38:31 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q44FcNmU021779 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 17:38:25 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 4 May 2012 17:38:24 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Date: Fri, 4 May 2012 17:38:23 +0200 Thread-Topic: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Ac0qAOTB9VU6yH6XQWm2u4EpQu+nRwACeWSg Message-ID: References: , , <4FA39884.1020304@packetizer.com> <4FA3E533.7070308@alum.mit.edu> In-Reply-To: <4FA3E533.7070308@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:38:33 -0000 And that is all callers and callees, not just a small subset of users who h= ave found their own convenient definition, but not told anyone else. For example, to someone who has spent 20 years in solitary confinement, the= analogue videophones that appeared in the early 90's would meet the defini= tion of the draft.=20 We need some real characteristics to define the concept, not subjective wor= ds like "in-person communication experience" Regards Keith -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Paul Kyzivat Sent: 04 May 2012 15:18 To: dispatch@ietf.org Subject: Re: [dispatch] FW: [sipcore] draft-lavers-sipcore-immersive-capabi= lity-00.txt On 5/4/12 4:51 AM, Paul E. Jones wrote: > I can't imagine why somebody would advertise that their fax device is > "immersive", but there would be no harm if they did. If the fax-only > device also advertised video, that would be a problem. If somebody advertised their fax-only device as immersive, then either=20 they made a mistake, or they have a different notion of what immersive=20 means than I do. But lacking a firm definition of immersive I guess they=20 could choose whatever meaning they want. But this then comes back to the=20 fundamental issue - that we need the caller and the callee to have a=20 common understanding of what this means. Thanks, Paul > The "immersive" feature was intended only to direct calls to devices > labeled as such in an effort to help ensure that if A calls B asking for > "immersive", then there is some reasonable chance that, if B had an > immersive device, the call would get routed to the right one. > > Paul > > On 5/3/2012 10:35 AM, Worley, Dale R (Dale) wrote: >>> From: dave Cruse [davecruse1@hotmail.com] >>> >>> I have some few basic questions here: >>> [...] >>> Q2. What if Endpoint support only FAX but not Video? >> I'm curious what the definition of "immersive fax" would be... >> >> Dale >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From prvs=1476341eb3=jbakker@rim.com Wed May 9 06:38:55 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED221F848E for ; Wed, 9 May 2012 06:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUYQ-rHmHZwU for ; Wed, 9 May 2012 06:38:54 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 739C421F8484 for ; Wed, 9 May 2012 06:38:54 -0700 (PDT) X-AuditID: 0a412830-b7fd36d000004206-50-4faa736cf6ca Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 57.77.16902.C637AAF4; Wed, 9 May 2012 13:38:53 +0000 (GMT) Received: from XCT103ADS.rim.net (10.67.111.44) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 9 May 2012 09:38:52 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.01.0339.001; Wed, 9 May 2012 08:38:51 -0500 From: John-Luc Bakker To: "dispatch@ietf.org" Thread-Topic: comments requested for draft-avasarala-dispatch-comm-div-notification-09 Thread-Index: AQHNLekR/vJMVZZeP0GsNzQddmt6pQ== Date: Wed, 9 May 2012 13:38:50 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> In-Reply-To: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsXC5bjwgm5u8Sp/gzdzGC2WTlrA6sDosWTJ T6YAxqgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzE zNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bns r2thYWqpa6hkp5vQyZOx+dln5oI1whWbH21maWB8I9TFyMkhIWAicezuG0YIW0ziwr31bF2M XBxCAn1MEivurGOEcJYzSvw7OxusSkhgE6PE2yVuIDabgLrE1hXbmUFsEQFtiaOrusBsYYFg iaVHVrNDxCMkTv5fwAhh60lcbXgHVMPBwSKgItF9TQokzCvgJrG5dS4LxHhHiYU7p4GN4RRw krjdeYsNxGYUkJXYffY6E4jNLCAucevJfCaIowUkluw5zwxhi0q8fPyPFcJWlPi79zsryCpm AU2J9bv0IVoVJaZ0P2SHWCsocXLmE6i1MhKtbbvYJjCKz0KyYRZC9ywk3bOQdC9gZFnFKJib UWxgZpicl6xXlJmrl5dasokRnCY0DHYwTtirdYhRgINRiYf3Rv4qfyHWxLLiytxDjBIczEoi vLPUV/oL8aYkVlalFuXHF5XmpBYfYrQABs9EZinu5HxgCssriTc2MEDhKInzRpss8RcSSAem o+zU1ILUIphWJg5OkNFcUiLFwKSSWpRYWpIRD0p98cXA5CfVwBhhGnk5UHF1+bqwgIVpHS9a eD6f/f/QbO1TpS9+vmdvGgjtOTdlT6v/gwcxIvus3uXpSOX9OX+99s38fv4LNi/m3tb69LnX +eNh/Qtn1VW5tNZfZGwokb/3VTOAKX5+x5qv9y5ln+P9f98jyTgyXzbge1CJ2FrehJyFG+o+ ea4+ppUkdyVAyVOJpTgj0VCLuag4EQDSPwTARwMAAA== Subject: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:38:55 -0000 SGksDQoNCkkgbGlrZSB0byBhbm5vdW5jZSB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBkcmFm dCBiZWxvdy4gDQpDb21tZW50cyByZWNlaXZlZCBkdXJpbmcgcHJldmlvdXMgcmV2aWV3cyBo YXZlIGJlZW4gYWRkcmVzc2VkLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCglKb2huLUx1Yw0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXks IE1hcmNoIDI3LCAyMDEyIDI6NTUgUE0NClRvOiBKb2huLUx1YyBCYWtrZXINCkNjOiByYW5q aXQuYXZhc2FyYWxhQHBvbHljb20uY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRp b24tMDkudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hdmFzYXJhbGEtZGlz cGF0Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTA5LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEpvaG4gTHVjIEJha2tlciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNv bW0tZGl2LW5vdGlmaWNhdGlvbg0KUmV2aXNpb246CSAwOQ0KVGl0bGU6CQkgQSBTZXNzaW9u IEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgRXZlbnQgUGFja2FnZSBmb3IgQ29tbXVuaWNh dGlvbiBEaXZlcnNpb24gSW5mb3JtYXRpb24gaW4gc3VwcG9ydCBvZiB0aGUgQ29tbXVuaWNh dGlvbiBEaXZlcnNpb24gKENESVYpIE5vdGlmaWNhdGlvbiAoQ0RJVk4pIENESVYgc2Vydmlj ZQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDMtMjcNCldHIElEOgkJIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyOQ0KDQpBYnN0cmFjdDoNCiAgIDNHUFAgYW5k IFRJU1BBTiBhcmUgZGVmaW5pbmcgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gZm9yIHRo ZQ0KICAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpIHNlcnZpY2UgdXNpbmcgSVAg TXVsdGltZWRpYSAoSU0pIENvcmUNCiAgIE5ldHdvcmsgKENOKSBzdWJzeXN0ZW0gc3VwcGxl bWVudGFyeSBzZXJ2aWNlLiAgQXMgcGFydCBvZiBDRElWLCBhIFNJUA0KICAgYmFzZWQgRXZl bnQgcGFja2FnZSBmcmFtZXdvcmsgaXMgdXNlZCBmb3Igbm90aWZ5aW5nIHVzZXJzIGFib3V0 DQogICBkaXZlcnNpb25zIChyZS1kaXJlY3Rpb25zIG9yIGZvcndhcmRpbmcpIG9mIHRoZWly IGluY29taW5nDQogICBjb21tdW5pY2F0aW9uIHNlc3Npb25zLiAgVGhpcyBkb2N1bWVudCBw cm9wb3NlcyBhIG5ldyBTSVAgZXZlbnQNCiAgIHBhY2thZ2UgZm9yIGFsbG93aW5nIHVzZXJz IHRvIHN1YnNjcmliZSB0byBhbmQgcmVjZWl2ZSBzdWNoDQogICBub3RpZmljYXRpb25zLiAg VXNlcnMgY2FuIGZ1cnRoZXIgZGVmaW5lIGZpbHRlcnMgdG8gY29udHJvbCB0aGUgcmF0ZQ0K ICAgYW5kIGNvbnRlbnQgb2Ygc3VjaCBub3RpZmljYXRpb25zLiAgVGhlIHByb3Bvc2VkIGV2 ZW50IHBhY2thZ2UgaXMNCiAgIGFwcGxpY2FibGUgdG8gdGhlIENESVYgc3VwcGxlbWVudGFy eSBzZXJ2aWNlIGluIElNUyBhbmQgbWF5IG5vdCBiZQ0KICAgYXBwbGljYWJsZSB0byB0aGUg Z2VuZXJhbCBpbnRlcm5ldC4gLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIHRyYW5z bWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0 ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxp Y2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlv bi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBs eSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0 aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBu b3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K From oej@edvina.net Wed May 9 07:19:29 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08E11E8079 for ; Wed, 9 May 2012 07:19:29 -0700 (PDT) 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=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jGW-bDsKG1g for ; Wed, 9 May 2012 07:19:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2BE11E8072 for ; Wed, 9 May 2012 07:19:27 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:100a] (unknown [IPv6:2001:16d8:cc57:1000::42:100a]) by smtp7.webway.se (Postfix) with ESMTPA id B2313754A8A2; Wed, 9 May 2012 14:19:25 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> Date: Wed, 9 May 2012 16:18:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <520B9CDF-84EA-45B2-9479-518056F8BAFC@edvina.net> References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> To: John-Luc Bakker X-Mailer: Apple Mail (2.1257) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:19:29 -0000 9 maj 2012 kl. 15:38 skrev John-Luc Bakker: > Hi, >=20 > I like to announce the availability of the draft below.=20 > Comments received during previous reviews have been addressed. While reading this for the first time I find it strange that this is = only aimed at the 3GPP application world. I see many cases where I have network-controlled call forwarding and = want all phones registred to my AOR to get information that the AOR is forwarded. Ideally I would like the SIP phone manufacturers to have their phones = subscribe to this package. Now if I press a DND button on my phone - will i PUBLISH an XML document = to update my status in the server and enable a service? The draft does = not mention anything about PUBLISH. /O= From pkyzivat@alum.mit.edu Wed May 9 07:58:29 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DD221F84FC for ; Wed, 9 May 2012 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiKg80xXr9xx for ; Wed, 9 May 2012 07:58:28 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4C21F84BF for ; Wed, 9 May 2012 07:58:28 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 7oN21j0051swQuc5BqyU2Y; Wed, 09 May 2012 14:58:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id 7qyU1j00W07duvL3bqyUQn; Wed, 09 May 2012 14:58:28 +0000 Message-ID: <4FAA8612.2070702@alum.mit.edu> Date: Wed, 09 May 2012 10:58:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:58:29 -0000 I have reviewed many versions of this draft. I'd appreciate it if somebody with a fresh set of eyes would give this a careful review. Thanks, Paul On 5/9/12 9:38 AM, John-Luc Bakker wrote: > Hi, > > I like to announce the availability of the draft below. > Comments received during previous reviews have been addressed. > > Kind regards, > > John-Luc > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, March 27, 2012 2:55 PM > To: John-Luc Bakker > Cc: ranjit.avasarala@polycom.com > Subject: New Version Notification for draft-avasarala-dispatch-comm-div-notification-09.txt > > A new version of I-D, draft-avasarala-dispatch-comm-div-notification-09.txt has been successfully submitted by John Luc Bakker and posted to the IETF repository. > > Filename: draft-avasarala-dispatch-comm-div-notification > Revision: 09 > Title: A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service > Creation date: 2012-03-27 > WG ID: Individual Submission > Number of pages: 29 > > Abstract: > 3GPP and TISPAN are defining the protocol specification for the > Communication Diversion (CDIV) service using IP Multimedia (IM) Core > Network (CN) subsystem supplementary service. As part of CDIV, a SIP > based Event package framework is used for notifying users about > diversions (re-directions or forwarding) of their incoming > communication sessions. This document proposes a new SIP event > package for allowing users to subscribe to and receive such > notifications. Users can further define filters to control the rate > and content of such notifications. The proposed event package is > applicable to the CDIV supplementary service in IMS and may not be > applicable to the general internet. . > > > > > The IETF Secretariat > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Wed May 9 08:44:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5521F8554 for ; Wed, 9 May 2012 08:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JysjL-iwIcBm for ; Wed, 9 May 2012 08:44:27 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id B210B21F8542 for ; Wed, 9 May 2012 08:44:27 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id 7rcb1j0011vXlb85CrkU2Z; Wed, 09 May 2012 15:44:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id 7rkT1j00C07duvL3drkUkg; Wed, 09 May 2012 15:44:28 +0000 Message-ID: <4FAA90DA.2080408@alum.mit.edu> Date: Wed, 09 May 2012 11:44:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:44:28 -0000 Comments on -09: Section 6.6 now mentions (at my request) "body part" rather than "body". But its not just any body part - this should say the check is for a body part with the appropriate content-type. Perhaps: The Notifier MUST check if the SUBSCRIBE request contains a body part having content-type "application/comm-div-info-filter+xml". If so the Notifier processes the filter criteria and generates notifications accordingly. Section 6.11: Is it really the intent that the state machine is affected by the subscriber filter? That seems wrong. That means that a subscription refresh that changes the filter criteria could lose an event. Also, is the FSM associated with the subscriber, or with the subscription? (IOW, if the same subscriber has two concurrent subscriptions, does it have two FSMs or one?) Maybe this works as you intend, but I bring it up in case it doesn't. (Also note that the first line of figure 1 is indented incorrectly.) Section 10: I just realized you have no MIME registrations for the mime types you use: "application/comm-div-info-ntfy+xml" and "application/comm-div-info-filter+xml". You really need that. And that would need to specify the association between the mime type and the xml scheme element contained in the mime type. That presents a little complexity because, based on the examples you have, one top level xml element for both mime types. I guess you can do that if you explain it well enough, though IMO it would make more sense to dispense with , and use as the top level element of "application/comm-div-info-filter+xml", and as the top level element of "application/comm-div-info-ntfy+xml" I think this document also requires a review by a MIME expert before it can be approved. Thanks, Paul From mary.ietf.barnes@gmail.com Fri May 11 14:02:51 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0B321F85E7 for ; Fri, 11 May 2012 14:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.636 X-Spam-Level: X-Spam-Status: No, score=-103.636 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUKHyEwKkdb0 for ; Fri, 11 May 2012 14:02:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2D021F854F for ; Fri, 11 May 2012 14:02:48 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3822398vbb.31 for ; Fri, 11 May 2012 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=giPiKkHcBh1tnn+1w/7XXLtcSI25RaupPIYHFCLOqEg=; b=e9gnFy5HMr6H4MS6Sg1dTmt1YU+QxWW6Jk/Siphh227EDzsvBx2Fvxu5Px0+D8wpH0 wN26UVagW62ih0PSZWCOQwVpwxMHQkZ0Q08EmOVPKfwKurXDnpYoD/viWakMfEE6sI9v EndYMVSV6q2jvvGKElAiLMdEqk1+3yEnm6QasnfPAMXvDJd9hm22Hg29Y8OZZd7mW6/6 evtSCAROmOXrw4QjBFJNAsipSPe0fZODiwcgE4LDUWN8TPIyTYTj4XSphhISlG477f1u XrwzNG0DO5ThJFOwEd255K9VBoWOID8d2kZx1/nHPL6OyPoZgSOZ4aUUlPdmh/p3mKu/ ZiOg== MIME-Version: 1.0 Received: by 10.52.92.204 with SMTP id co12mr1349090vdb.105.1336770167935; Fri, 11 May 2012 14:02:47 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Fri, 11 May 2012 14:02:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 May 2012 16:02:47 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=bcaec50162f30192be04bfc90f14 Cc: Cullen Jennings , rai-ads@tools.ietf.org Subject: [dispatch] IETF-84 DISPATCH deadlines. X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:02:51 -0000 --bcaec50162f30192be04bfc90f14 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Per the discussion at IETF-83, there was (again) pushback on the model we have had in place for several years for DISPATCH topics. The chairs and ADs have had some offline discussions and we are proposing changing the dates. Note, that these dates do not allow time to schedule Bofs for any of the topics, but it does still allow some forewarning and discussion of topics. These dates require us to request a WG session without a preliminary agenda. If there is not enough discussion of topics, we will cancel the WG session. Here are the proposed deadlines: * June 11, 2012. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [One week after deadline for scheduling WG sessions] * June 18, 2012. Cutoff for charter proposals for topics. [Note: this is two weeks *after* requests for WG sessions] * June 25, 2012. Topics that are to be the focus of IETF-84 are announced. [2 weeks before -00 deadline, *three weeks* after deadline for requesting WG session] * July 9, 2012. -00 draft deadline. * July 16, 2012. Draft deadline. This gives folks one month from today to get their topics to the chairs and then another week to charters, problem statements, deliverables, etc. to the mailing list. As a reference these are the dates we presented at IETF-83 and that are currently on the wiki. We will update the wiki with the new dates unless we get strong objections (which I can't fathom we would). * May 21, 2012. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to deadline for scheduling WG sessions] [7 weeks after IETF-83] * May 28, 2012. Cutoff for charter proposals for topics. [Three weeks prior to BoF proposal deadline, two weeks before announcement of topics] * June 11, 2012. Topics that are to be the focus of IETF-84 are announced. [Ten days before AD BoF approval, 4 weeks before -00 deadline, *one week* after deadline for requesting WG session] * July 9, 2012. -00 draft deadline. * July 16, 2012. Draft deadline. Regards, Mary. DISPATCH WG co-chair --bcaec50162f30192be04bfc90f14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Per the discussion at IETF-83, there was (again)= pushback on the model we have had in place for several years for DISPATCH = topics. =A0The chairs and ADs have had some offline discussions and we are = proposing changing the dates. =A0Note, that these dates do not allow time t= o schedule Bofs for any of the topics, but it does still allow some forewar= ning and discussion of topics. These dates require us to request a WG sessi= on without a preliminary agenda. =A0If there is not enough discussion of to= pics, we will cancel the WG session. =A0

Here are the proposed deadlines:
* June 11, 2012. Cutoff = date to notify the chairs/DISPATCH WG of plans to submit a proposal. [One w= eek after deadline for scheduling WG sessions] =A0

* June 18, 2012. Cutoff for charter proposals for topic= s. [Note: this is two weeks *after* requests for WG sessions]
* June 25, 2012. Topics that are to be the focus of=A0IETF-84=A0are announced. [2 we= eks before -00 deadline, *three weeks* after deadline for requesting WG ses= sion]

* July 9= , 2012. -00 draft deadline.

* July 16, 2012. Draft= deadline.

This gives folks one month from today t= o get their topics to the chairs and then another week to charters, problem= statements, deliverables, etc. to the mailing list.=A0

As a reference these are the dates we presented= at IETF-83 and that are currently on the wiki. =A0We will update the wiki = with the new dates unless we get strong objections (which I can't fatho= m we would). =A0

* May 21, 2012. Cutoff = date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two w= eeks prior to deadline for scheduling WG sessions] =A0 [7 weeks after IETF-= 83]

* May 28, 2012. Cutoff for charter proposals for topics= . [Three weeks prior to BoF proposal deadline, two weeks before announcemen= t of topics]

* June 11, 2012. Topics that are to b= e the focus of IETF-84 are announced. [Ten days before AD BoF approval, 4 w= eeks before -00 deadline, *one week* after deadline for requesting WG sessi= on]

* July 9, 2012. -00 draft deadline.

* July 16, 2012. Draft deadline.

Regards,
Mary.
DISPATCH WG co-chair

--bcaec50162f30192be04bfc90f14-- From prvs=4482990da1=jbakker@rim.com Tue May 15 15:37:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B75A21F873D for ; Tue, 15 May 2012 15:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.436 X-Spam-Level: X-Spam-Status: No, score=-5.436 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rnyqpLH9pKE for ; Tue, 15 May 2012 15:37:22 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0D44E21F8471 for ; Tue, 15 May 2012 15:37:20 -0700 (PDT) X-AuditID: 0a41282f-b7f0d6d0000047cd-bc-4fb2da9fe871 Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 4F.F4.18381.F9AD2BF4; Tue, 15 May 2012 22:37:19 +0000 (GMT) Received: from XCT105ADS.rim.net (10.67.111.46) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 15 May 2012 18:37:19 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.01.0339.001; Tue, 15 May 2012 17:37:18 -0500 From: John-Luc Bakker To: Gonzalo Camarillo Thread-Topic: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Thread-Index: AQHNHVOLGaoZosgWp06CrMLzAfa1kZbLjn1A Date: Tue, 15 May 2012 22:37:17 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> In-Reply-To: <4F8EA090.1010400@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsXC5bjwnO78W5v8DY7tNLNYOmkBq8Wm5SuZ LFZsOMDqwOzx9/0HJo9fX6+yeSxZ8pMpgDmqgdEmKbGkLDgzPU/fziYxLy+/JLEkVSEltTjZ VsknNT0xRyGgKLMsMblSwSWzODknMTM3tUhJITPFVslESaEgJzE5NTc1r8RWKbGgIDUvRcmO SwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2ekmdPJk/Oq9zV7wPqDiTKN0A+Nhpy5G Tg4JAROJxZMuM0HYYhIX7q1nA7GFBPqYJP6vL+xi5AKyVzBK/Pu0nw3C2cwoMedMFwtIFZuA usTWFduZQWwRATOJ9/9WgU1iFgiW2HBmCiuILSxgL/FnzV4WiBoHidYFPVD1RhJX3s0Gs1kE VCW2ft3NDmLzCrhJ/Gt6xQixbDeTRPfS9WBFnAI6Etf+/AdbwAh06vdTa6CWiUvcejIf6gUB iSV7zjND2KISLx//Y4WwFSX+7v3OClGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wgLxvoxEa9su tgmMErOQrJiFpH0WkvZZSNoXMLKsYhTMzSg2MDNIzkvWK8rM1ctLLdnECE42Gvo7GPv2ah1i FOBgVOLh3Xl2k78Qa2JZcWXuIUYJDmYlEV4xM6AQb0piZVVqUX58UWlOavEhRgtgEE1kluJO zgcmwrySeGMDAxSOkjhvlMkSfyGBdGCyyk5NLUgtgmll4uAEGc0lJVIMTDmpRYmlJRnxoMQY XwxMjVINjAWKjx6rXJ/xwneG5fIXYTW5tZkLE5I8OqfU3F+mq58g1uGQm+LBle8k8iyRN/Ha l2TeryczP2Svbrv71+io/ZU4rtK4hRv6Fe12b1nXtanugmKn0rHFRWe+nNl+ddqZb3ILjZbO uqG1+FeBlIn7Wj/T0pfXfiSte1h4fO2bqUEtOTK7bwcrzldiKc5INNRiLipOBABZUbt5agMA AA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 22:37:23 -0000 Hi, Thanks for reviewing the draft. Please see inline. Kind regards, John-Luc -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Wednesday, April 18, 2012 6:08 AM To: John-Luc Bakker Cc: Paul Kyzivat; dispatch@ietf.org Subject: Re: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Hi John Luc, it is important that the DISPATCH community understands how you would like t= o progress this draft so that they provide their input. Per RFC 2183, the re= gistration of disposition types requires a Standards Track or an IESG-Approv= ed Experimental RFC: http://www.iana.org/assignments/mail-cont-disp/mail-cont-disp.xml#mail-cont-= disp-1 You draft seems to aim to become an Experimental RFC, right? JL: Yes, that is the intention. I guess the reasons for this RFC to be Experimental are given in Section 1 of the draft, right? http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling-0= 8#section-1 JL: Yes. I assume you considered Section 8 of RFC 5621 when deciding disposition type= s were the right tool for what you need to do: http://www.iana.org/assignments/media-types/application/3gpp-ims+xml JL: Yes. And in addition, the ' 3GPP IM CN Subsystem XML body' has been arou= nd longer than RF 5621. Thanks, Gonzalo On 09/04/2012 5:47 PM, John-Luc Bakker wrote: > Dear Paul, Gonzalo, > > I received an editorial comment on this draft. The draft is referring to s= ections 2.2, 2.3 and 2.1. These references should have been 4.2.1, 4.2.2 and= 4.2.3. > > Have you had an oppertunity to further digest the draft in light of our pr= evious offline discussion? > > Kind regards, > > John-Luc > > -----Original Message----- > From: John-Luc Bakker > Sent: Tuesday, March 27, 2012 12:37 PM > To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com > Cc: dispatch@ietf.org > Subject: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: > [dispatch] I-D Action: > draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) > > Dear all, > > I have just made revision 8 of draft-bakker-sipping-3gpp-ims-xml-body-hand= ling available following offline discussion. Biggest addition is the new sec= tion 2.1 which aims to further motivate the need for the ID. > > You can find the HTML formatted version here: > http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-hand > ling-08 > > I am looking forward to hearing about any concerns you may have. > > Kind regards, > > John-Luc > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of John-Luc Bakker > Sent: Tuesday, March 20, 2012 1:53 PM > To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com > Cc: dispatch@ietf.org; sipping > Subject: Re: [dispatch] I-D Action: > draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt > > Hi, > > Thanks, Paul for reviewing the draft. > Appologies for having delayed this response. > > Let me address first the question about this being a SIPPING draft: I inte= nd to ask Gonzallo to sponsor this draft. To collect any further comments an= d ensure visibility (sine the sipping list is obsolete), I have copied the D= ISPATCH list. > > See also inline with . > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Saturday, December 03, 2011 12:11 PM > To: John-Luc Bakker > Cc: sipping > Subject: Re: I-D Action: > draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt > > I'm commenting on this on the (now obsolete) sipping list because this > has sipping in its name. This may not be the best place. I suppose an > alternative is rai. > > ISTM that there are three degrees of freedom here for identifying how > to process these bodies: > - content-disposition > - content-type > - the actual content of the body > > Of these, the content-disposition is the most heavy weight in terms of > mechanism, while the actual content of the body is the least heavy-weight. > > So, I wonder why you have chosen to use one content-type, that seems > to already contain distinct representations for the differing > behaviors of interest, and yet use distinct content-dispositions. I > think you could use a single content-disposition and get the same effect. > > I guess multiple content-dispositions might make sense if they are > processed by different entities, so that only the intended entities > need decode the body. > > The reason for having two content dispositions is because there are d= ifferent behaviors for the same content-type when received by different enti= ties. > There are two different entities that apply a different behavior when= receiving the body, say behavior A and behavior B. However, XML elements pr= esent in the body trigger behavior A (in the abstract of the draft, behavior= (2)) by entity A and if not present, no further behavior by entity A is spe= cified in this draft. Other XML elements present in the body trigger one of= a set of behaviors B (in the abstract of the draft, behaviors (1) and (3))= by entity B and if not present, no further behavior by entity B is specifie= d in this draft. > > It would also make sense if the same identical body representation was > processed differently based on the content-disposition. > > The bodies triggering the different behaviors are indeed not identica= l. > However, the content-dispositions are processed by different entities= , which is a reason for proposing these content-disposition values. > > But I don't think either of those is the case here. So I would find it hel= pful if this draft explained why it chooses to use multiple content-disposit= ions. > > The draft illustrates that, in IMS, different entities receive bodies= with the content-type, and apply different behaviors. The draft further sug= gests that the applicability of these values may be limited to IMS. Do you s= ee a need for a general discussion of this approach since the applicability= is limited to IMS? > > I also think it would be useful to say something about how you expect > the handling parameter to be used with these dispositions. If > handling=3Drequired (the default) is used, then any UA that gets this > must fail the request unless it is able to handle the body. If > handling=3Doptional is specified, then that need not be so. > > The handling parameter is mentioned in RFC 3261 and this draft refers= to that RFC. RFC 3261 refers to RFC 3204. This draft does not change the be= havior and interpretation of the parameter and its values. It should not be= necessary to repeat what has already been documented in RFC 3261. Do you se= e different behavior that goes beyond what has been documented? > > Thanks, > Paul > > On 12/3/11 5:08 AM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> >> Title : Specification of 3GPP IM CN Subsystem XML body handlin= g >> Author(s) : John-Luc Bakker >> Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >> Pages : 7 >> Date : 2011-12-02 >> >> This document registers new disposition-types for the Content- >> Disposition header field that apply to the application/3gpp-ims+xml >> body used by 3GPP. The applicability of these content-disposition >> values are limited to 3GPP IMS. The application/3gpp-ims+xml body >> has the following three distinct uses: (1) for redirecting the >> emergency session to use a different domain (e.g. using a Circuit >> Switched call), (2) for delivering user profile specific information >> from the SIP registrar to an Application Server, and (3) for causing >> a UAC to attempt to re-register with the IMS. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml >> -body-handling-07.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml- >> body-handling-07.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From Ranjit.Avasarala@Polycom.com Wed May 16 02:24:16 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1921F87E3 for ; Wed, 16 May 2012 02:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxiI+B1DZAac for ; Wed, 16 May 2012 02:24:12 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 825E621F87D7 for ; Wed, 16 May 2012 02:24:06 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Wed, 16 May 2012 17:24:05 +0800 From: "Avasarala, Ranjit" To: "Olle E. Johansson" , John-Luc Bakker Date: Wed, 16 May 2012 17:24:02 +0800 Thread-Topic: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 Thread-Index: Ac0t7sOpISiCoaTnR36S3QwjNFY1NQFVnQBg Message-ID: <1F2A2C70609D9E41844A2126145FC09804BD10A648@HKGMBOXPRD22.polycom.com> References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> <520B9CDF-84EA-45B2-9479-518056F8BAFC@edvina.net> In-Reply-To: <520B9CDF-84EA-45B2-9479-518056F8BAFC@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 09:24:17 -0000 Hi Oile Though the abstract of the draft mentions 3GPP and IMS, the CDIVN service a= nd the proposed event package holds good for any SIP based VoIP networks. S= o you could look at it as a generic SIP based event notification and event = package conforming to RFC 3265.=20 Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Olle E. Johansson Sent: Wednesday, May 09, 2012 7:48 PM To: John-Luc Bakker Cc: dispatch@ietf.org Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-com= m-div-notification-09 9 maj 2012 kl. 15:38 skrev John-Luc Bakker: > Hi, >=20 > I like to announce the availability of the draft below.=20 > Comments received during previous reviews have been addressed. While reading this for the first time I find it strange that this is only a= imed at the 3GPP application world. I see many cases where I have network-controlled call forwarding and want a= ll phones registred to my AOR to get information that the AOR is forwarded. Ideally I would like the SIP phone manufacturers to have their phones subsc= ribe to this package. Now if I press a DND button on my phone - will i PUBLISH an XML document to= update my status in the server and enable a service? The draft does not me= ntion anything about PUBLISH. /O _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Ranjit.Avasarala@Polycom.com Wed May 16 02:32:36 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D562521F854E for ; Wed, 16 May 2012 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6utt9AkICQm for ; Wed, 16 May 2012 02:32:29 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3593721F855A for ; Wed, 16 May 2012 02:32:27 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Wed, 16 May 2012 17:32:26 +0800 From: "Avasarala, Ranjit" To: Paul Kyzivat Date: Wed, 16 May 2012 17:32:24 +0800 Thread-Topic: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 Thread-Index: Ac0t+qOvC4PABI7BTJ+i1WOxDI8LLAFSxXMw Message-ID: <1F2A2C70609D9E41844A2126145FC09804BD10A64D@HKGMBOXPRD22.polycom.com> References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> <4FAA90DA.2080408@alum.mit.edu> In-Reply-To: <4FAA90DA.2080408@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 09:32:36 -0000 Hi Paul Yes I agree with you that we need to register the 2 XML body types - applic= ation/comm-div-info-ntfy+xml" and "application/comm-div-info-filter+xml as = MIME type registrations. Sorry we missed that.=20 Section 6.11: Is it really the intent that the state machine is affected by the subscribe= r filter? That seems wrong. That means that a subscription refresh that cha= nges the filter criteria could lose an event. Also, is the FSM associated w= ith the subscriber, or with the subscription? (IOW, if the same subscriber = has two concurrent subscriptions, does it have two FSMs or one?) FSM is actually associated with the call diversion service and not= with the subscriber / subscription. The state changes and notifications b= eing sent or not depend on subscription. For e.g. if the subscriber has set= a filter not to send notifications for diversions that occur between 9 PM = and 6 AM, then the state would not transition to "Diversion Notified" for t= hat particular diversion. Rather it would transition to "Diversion Not Noti= fied".=20 Let us know if there are any other comments before we can update the doc Thanks Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Paul Kyzivat Sent: Wednesday, May 09, 2012 9:14 PM To: dispatch@ietf.org Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-com= m-div-notification-09 Comments on -09: Section 6.6 now mentions (at my request) "body part" rather than "body".=20 But its not just any body part - this should say the check is for a body pa= rt with the appropriate content-type. Perhaps: The Notifier MUST check if the SUBSCRIBE request contains a body part having content-type "application/comm-div-info-filter+xml". If so the Notifier processes the filter criteria and generates notifications accordingly. Section 6.11: Is it really the intent that the state machine is affected by the subscribe= r filter? That seems wrong. That means that a subscription refresh that cha= nges the filter criteria could lose an event. Also, is the FSM associated w= ith the subscriber, or with the subscription? (IOW, if the same subscriber = has two concurrent subscriptions, does it have two FSMs or one?) Maybe this works as you intend, but I bring it up in case it doesn't. (Also note that the first line of figure 1 is indented incorrectly.) Section 10: I just realized you have no MIME registrations for the mime types you use: "application/comm-div-info-ntfy+xml" and "application/comm-div-info-fi= lter+xml". You really need that. And that would need to specify the association between the mime type and th= e xml scheme element contained in the mime type. That presents a little com= plexity because, based on the examples you have, one top level xml element = for both mime types. I guess you can do that if you explain it well enough,= though IMO it would make more sense to dispense with , and = use as the top level element of "application/comm-div-= info-filter+xml", and as the top level element of "app= lication/comm-div-info-ntfy+xml" I think this document also requires a review by a MIME expert before it can= be approved. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Wed May 16 07:25:58 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B4B21F853F for ; Wed, 16 May 2012 07:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lEVQig6AnsU for ; Wed, 16 May 2012 07:25:58 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id D892421F84C8 for ; Wed, 16 May 2012 07:25:57 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id AcY21j0041c6gX85BeRyHv; Wed, 16 May 2012 14:25:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id AeRx1j00r07duvL3jeRy01; Wed, 16 May 2012 14:25:58 +0000 Message-ID: <4FB3B8F4.7070209@alum.mit.edu> Date: Wed, 16 May 2012 10:25:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Avasarala, Ranjit" References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> <4FAA90DA.2080408@alum.mit.edu> <1F2A2C70609D9E41844A2126145FC09804BD10A64D@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BD10A64D@HKGMBOXPRD22.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:25:58 -0000 On 5/16/12 5:32 AM, Avasarala, Ranjit wrote: > Hi Paul > > Yes I agree with you that we need to register the 2 XML body types - application/comm-div-info-ntfy+xml" and "application/comm-div-info-filter+xml as MIME type registrations. Sorry we missed that. OK. As things stand I presume you would define them both as requiring the content to conform to the schema for . But IIUC there is a further restriction - that application/comm-div-info-ntfy+xml must match ... and application/comm-div-info-filter+xml must match ... But if that is so, it seems that serves no purpose at all. It would be simpler, clearer, and a tiny bit smaller to dispense with it and just have application/comm-div-info-ntfy+xml conform to , and application/comm-div-info-filter+xml conform to . > Section 6.11: > > Is it really the intent that the state machine is affected by the subscriber filter? That seems wrong. That means that a subscription refresh that changes the filter criteria could lose an event. Also, is the FSM associated with the subscriber, or with the subscription? (IOW, if the same subscriber has two concurrent subscriptions, does it have two FSMs or one?) > > FSM is actually associated with the call diversion service and not with the subscriber / subscription. The state changes and notifications being sent or not depend on subscription. For e.g. if the subscriber has set a filter not to send notifications for diversions that occur between 9 PM and 6 AM, then the state would not transition to "Diversion Notified" for that particular diversion. Rather it would transition to "Diversion Not Notified". We have had a long running conversation over the versions regarding the state model. Your comment here reopens that discussion. I asked the question because of the text at the beginning of 6.11: An FSM associated with the subscriber is created in the "IDLE" state, e.g. upon receiving filter criteria. It says that an FSM is associated with a subscriber. If that isn't what you mean, then you should write down what you do mean. Thanks, Paul > Let us know if there are any other comments before we can update the doc > > Thanks > > Regards > Ranjit > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, May 09, 2012 9:14 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 > > Comments on -09: > > Section 6.6 now mentions (at my request) "body part" rather than "body". > But its not just any body part - this should say the check is for a body part with the appropriate content-type. Perhaps: > > The Notifier MUST check if the SUBSCRIBE request contains a body > part having content-type "application/comm-div-info-filter+xml". > If so the Notifier processes the filter criteria and generates > notifications accordingly. > > Section 6.11: > > Is it really the intent that the state machine is affected by the subscriber filter? That seems wrong. That means that a subscription refresh that changes the filter criteria could lose an event. Also, is the FSM associated with the subscriber, or with the subscription? (IOW, if the same subscriber has two concurrent subscriptions, does it have two FSMs or one?) > > Maybe this works as you intend, but I bring it up in case it doesn't. > > (Also note that the first line of figure 1 is indented incorrectly.) > > Section 10: > > I just realized you have no MIME registrations for the mime types you > use: "application/comm-div-info-ntfy+xml" and "application/comm-div-info-filter+xml". You really need that. > > And that would need to specify the association between the mime type and the xml scheme element contained in the mime type. That presents a little complexity because, based on the examples you have, one top level xml element for both mime types. I guess you can do that if you explain it well enough, though IMO it would make more sense to dispense with, and use as the top level element of "application/comm-div-info-filter+xml", and as the top level element of "application/comm-div-info-ntfy+xml" > > I think this document also requires a review by a MIME expert before it can be approved. > > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From henry.peter@dialogic.com Tue May 22 22:29:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDCD21F8568 for ; Tue, 22 May 2012 22:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfw36E-2ebJB for ; Tue, 22 May 2012 22:29:26 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [173.210.122.27]) by ietfa.amsl.com (Postfix) with ESMTP id 83CFD21F855D for ; Tue, 22 May 2012 22:29:25 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht01.dialogic.com ([::1]) with mapi; Wed, 23 May 2012 01:29:25 -0400 From: Henry Peter To: "dispatch@ietf.org" Date: Wed, 23 May 2012 01:29:14 -0400 Thread-Topic: Need a resolution on the usage of SIP OPTIONS -b4- Thread-Index: Ac04pP2Kn+MHO6N9Qm6o/u5UHsBFSw== Message-ID: <83E4421E2AC24F4398191DD444E407140FE9F0EB@MBX.dialogic.com> 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_83E4421E2AC24F4398191DD444E407140FE9F0EBMBXdialogiccom_" MIME-Version: 1.0 Subject: [dispatch] Need a resolution on the usage of SIP OPTIONS -b4- X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 05:29:28 -0000 --_000_83E4421E2AC24F4398191DD444E407140FE9F0EBMBXdialogiccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I have encountered a scenario regarding the usage of SIP OPTIONS and need a= resolution. I went thru some of the discussions of the past on the usage = of SIP OPTIONS as a ping mechanism and it looks like I am not getting a con= crete answer to what I am looking for. >From RFC 3261 the primary intention of SIP OPTION being to query the capabi= lities of a SIP UA. This is evident from Section 4, "Additional operations in SIP, such as quer= ying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, will be introduced in later sections. " The same is mentioned in section 7.1, 8.1.1, and finally 11. Also from Section 11 it is clear that OPTIONS should not have to be generat= ed only with Max-Forwards of 70. In fact a value of 0 makes perfect sense = for some scenarios. The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request. Alternatively, a server receiving an OPTIONS request with a Max- Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values. Now in Section 11.2, it gets interesting. I can only derive that the UAS c= onveying its readiness to accept a call, that is an INVITE, is part of its = capability, in order to maintain the previous emphasis of the reasoning beh= ind the inception of OPTIONS. 11.2 Processing of OPTIONS= Request The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. Now I will get to the problem I am facing. A UA has identified a specific = remote server of IP and Port to be used in sending INVITEs to establish ses= sions. It wants to find out if that remote server is ready to accept INVIT= E, for any reasons; it need not necessarily be an overload but can even be = an administrative "lock", a license capacity issue,, etc., So the UA initiates a SIP OPTION and since it is a specific remote server i= t creates a Max-Forwards (MF) of 1. The Req-Uri specifically has IP and Po= rt. One can argue the MF can even be 0. However the remote server is actu= ally sending a 400 Bad Request because it does not like the "1" in MF and i= n fact expects "70". It seems (from other vendor's/implementations point o= f view) that is what RFC 3261 is requiring although I don't see how. How to clarify this situation? It would have been nice if the RFC 3261 was= very explicit about the role of MF in the SIP OPTIONS although it does hin= t with traceroute example. When trying to set the MF in SIP OPTIONS (as a 70 did not fit the scenario)= , in our search for a follow-up after RFC 3261 on the usage of SIP OPTIONS = we could only find the draft (http://tools.ietf.org/html/draft-jones-sip-op= tions-ping-02 ) which recommended using a value of "1" that was much better= off than 70. Is there a plan to standardize certain of these mechanisms as a best-practi= ce? Any suggestion or comments are appreciated. Thanks. Best Regards, Henry Peter Henry Peter | Dialogic Inc. | henry.peter@dialogic.com 209 207 8446 M | 209 836 0737 W1 | 408 750 9428 W2 --_000_83E4421E2AC24F4398191DD444E407140FE9F0EBMBXdialogiccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I have = encountered a scenario regarding the usage of SIP OPTIONS and need a resolu= tion.  I went thru some of the discussions of the past on the usage of= SIP OPTIONS as a ping mechanism and it looks like I am not getting a concr= ete answer to what I am looking for. 

 

From RFC 3261 the primary int= ention of SIP OPTION being to query the capabilities of a SIP UA. 

 

This is evident =
from Section 4, “Additional operations in SIP, such as querying=
 for the capabilities

   of a = SIP server or client using OPTIONS, or canceling a pending

   request using CANCEL, will be introduc= ed in later sections.

= “

&n= bsp;

The same is mentioned in section 7.1, 8.= 1.1, and finally 11.

 

Also from Section 11 it is clear that OPTIONS should= not have to be generated only with Max-Forwards of 70.  In fact a val= ue of 0 makes perfect sense for some scenarios.

 

 

The target of the OPTIONS request is identified by the Request-URI,<= o:p>
   which could identify anothe=
r UA or a SIP server.  If the OPTIONS is
=
   addressed to a proxy server, the Request-URI is set with=
out a user
   part, similar to=
 the way a Request-URI is set for a REGISTER request.
 
 
Alternatively, a server =
receiving an OPTIONS request with a Max-
   Forwards header field value of 0 MAY respond to the request
   regardless of the Request-UR=
I.
 
<=
b>      This behavior is common with HTTP/1.1.&=
nbsp; This behavior can be used
 &n=
bsp;    as a "traceroute" functionality to check t=
he capabilities of
   &nb=
sp;  individual hop servers by sending a series of OPTIONS requests
      with increm=
ented Max-Forwards values.
 
 
Now in Section 11.2, it gets interesting.  I can only derive tha=
t the UAS conveying its readiness to accept a call, that is an INVITE, is p=
art of its capability, in order to maintain the previous emphasis of the re=
asoning behind the inception of OPTIONS.
 
 
11.2<=
span style=3D'font-family:"Courier New"'> Processing of OPTIONS Request
 
 
   The response to an OPTIONS is constructe=
d using the standard rules
   for a S=
IP response as discussed in Section 8.2.6.  The response code
   chosen MUST be the same that would have been chosen =
had the request
   been an INVITE.&nb=
sp; That is, a 200 (OK) would be returned if the UAS is
   ready to accept a call, a 486 (B=
usy Here) would be returned if the
  =
 UAS is busy, etc.  This allows an OPTIONS request to be used to<=
/o:p>
   determine the basic state of a UAS, whi=
ch can be an indication of
   whether=
 the UAS will accept an INVITE request.
 
 
Now I will get to the problem I am facing.  A UA has id=
entified a specific remote server of IP and Port to be used in sending INVI=
TEs to establish sessions.  It wants to find out if that remote server=
 is ready to accept INVITE, for any reasons; it need not necessarily be an =
overload but can even be an administrative “lock”, a license ca=
pacity issue,, etc.,
 
So the UA initiates a SIP OPTION and since it is a s=
pecific remote server it creates a Max-Forwards (MF) of 1.  The Req-Ur=
i specifically has IP and Port.  One can argue the MF can even be 0.&n=
bsp; However the remote server is actually sending a 400 Bad Request becaus=
e it does not like the “1” in MF and in fact expects “70&=
#8221;.  It seems (from other vendor’s/implementations point of =
view) that is what RFC 3261 is requiring although I don’t see how.
 
=
How to clarify this situation?  It would have been nice if the RFC 326=
1 was very explicit about the role of MF in the SIP OPTIONS although it doe=
s hint with traceroute example.  
<=
o:p> 
When trying to set the MF in SIP O=
PTIONS (as a 70 did not fit the scenario), in our search for a follow-up af=
ter RFC 3261 on the usage of SIP OPTIONS we could only find the draft (http://t=
ools.ietf.org/html/draft-jones-sip-options-ping-02 ) which recommended =
using a value of “1” that was much better off than 70.
 
Is the=
re a plan to standardize certain of these mechanisms as a best-practice?&nb=
sp; Any suggestion or comments are appreciated.  Thanks.
Best Regards,
Henry Peter=

H=
enry Peter | Dialogic Inc. | he=
nry.peter@dialogic.com
209 207 8446&=
nbsp;M | 209 836 0737 W1 | 408 750 9428 W2
 
= --_000_83E4421E2AC24F4398191DD444E407140FE9F0EBMBXdialogiccom_-- From pkyzivat@alum.mit.edu Wed May 23 07:45:53 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E194621F86F0 for ; Wed, 23 May 2012 07:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhznqgY1J0cK for ; Wed, 23 May 2012 07:45:53 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id F175D21F86D1 for ; Wed, 23 May 2012 07:45:51 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id DScN1j00H0xGWP85FSlrDM; Wed, 23 May 2012 14:45:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id DSlq1j01f07duvL3YSlr9L; Wed, 23 May 2012 14:45:51 +0000 Message-ID: <4FBCF81E.40300@alum.mit.edu> Date: Wed, 23 May 2012 10:45:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <83E4421E2AC24F4398191DD444E407140FE9F0EB@MBX.dialogic.com> In-Reply-To: <83E4421E2AC24F4398191DD444E407140FE9F0EB@MBX.dialogic.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Need a resolution on the usage of SIP OPTIONS -b4- X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:45:54 -0000 Henry, Questions such as this belong on the sip-implementors list, not the dispatch list. I will respond to you there. Thanks, Paul On 5/23/12 1:29 AM, Henry Peter wrote: > Folks, > > I have encountered a scenario regarding the usage of SIP OPTIONS and > need a resolution. I went thru some of the discussions of the past on > the usage of SIP OPTIONS as a ping mechanism and it looks like I am not > getting a concrete answer to what I am looking for. > > From RFC 3261 the primary intention of SIP OPTION being to query the > capabilities of a SIP UA. > > This is evident from Section 4,*/“Additional operations in SIP, such as querying for the capabilities/* > > */of a SIP server or client using OPTIONS, or canceling a pending/* > > */request using CANCEL, will be introduced in later sections./* > > */“/**//* > > The same is mentioned in section 7.1, 8.1.1, and finally 11. > > Also from Section 11 it is clear that OPTIONS should not have to be > generated only with Max-Forwards of 70. In fact a value of 0 makes > perfect sense for some scenarios. > > */The target of the OPTIONS request is identified by the Request-URI,/* > > */ which could identify another UA or a SIP server. If the OPTIONS is/* > > */ addressed to a proxy server, the Request-URI is set without a user/* > > */ part, similar to the way a Request-URI is set for a REGISTER request./* > > *//* > > *//* > > */Alternatively, a server receiving an OPTIONS request with a Max-/* > > */ Forwards header field value of 0 MAY respond to the request/* > > */ regardless of the Request-URI./* > > */ /* > > */ This behavior is common with HTTP/1.1. This behavior can be used/* > > */ as a"traceroute" functionality to check the capabilities of/* > > */ individual hop servers by sending a series of OPTIONS requests/* > > */ with incremented Max-Forwards values./* > > Now in Section 11.2, it gets interesting. I can only derive that the UAS > conveying its readiness to accept a call, that is an INVITE, is part of > its capability, in order to maintain the previous emphasis of the > reasoning behind the inception of OPTIONS. > > > > > 11.2 /Processing > of OPTIONS Request/ > > / / > > / / > > / The response to an OPTIONS is constructed using the standard rules/ > > / for a SIP response as discussed inSection 8.2.6 . The response code/ > > / chosen MUST be the same that would have been chosen had the request/ > > / been an INVITE. *That is, a 200 (OK) would be returned if the UAS is*/ > > */ ready to accept a call,/*/ a 486 (Busy Here) would be returned if the/ > > / UAS is busy, etc. This allows an OPTIONS request to be used to/ > > / determine the basic state of a UAS, which can be an indication of/ > > / whether the UAS will accept an INVITE request./ > > Now I will get to the problem I am facing. A UA has identified a > specific remote server of IP and Port to be used in sending INVITEs to > establish sessions. It wants to find out if that remote server is ready > to accept INVITE, for any reasons; it need not necessarily be an > overload but can even be an administrative “lock”, a license capacity > issue,, etc., > > So the UA initiates a SIP OPTION and since it is a specific remote > server it creates a Max-Forwards (MF) of 1. The Req-Uri specifically has > IP and Port. One can argue the MF can even be 0. However the remote > server is actually sending a 400 Bad Request because it does not like > the “1” in MF and in fact expects “70”. It seems (from other > vendor’s/implementations point of view) that is what RFC 3261 is > requiring although I don’t see how. > > How to clarify this situation? It would have been nice if the RFC 3261 > was very explicit about the role of MF in the SIP OPTIONS although it > does hint with traceroute example. > > When trying to set the MF in SIP OPTIONS (as a 70 did not fit the > scenario), in our search for a follow-up after RFC 3261 on the usage of > SIP OPTIONS we could only find the draft > (http://tools.ietf.org/html/draft-jones-sip-options-ping-02 ) which > recommended using a value of “1” that was much better off than 70. > > Is there a plan to standardize certain of these mechanisms as a > best-practice? Any suggestion or comments are appreciated. Thanks. > > /Best Regards/, > > Henry Peter > > Henry Peter | Dialogic Inc. | henry.peter@dialogic.com > > 209 207 8446 M | 209 836 0737 W1 | 408 750 9428 W2 > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From rifatyu@avaya.com Sat May 26 14:23:00 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2209B21F850F for ; Sat, 26 May 2012 14:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySrOSoovuNdI for ; Sat, 26 May 2012 14:22:59 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3A21A21F8501 for ; Sat, 26 May 2012 14:22:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPZIwU/GmAcF/2dsb2JhbABEtRmBB4IeElYjAQwBCGsnBBsah2kLlyuEIJwMBI9iYAOIDJJ8igCCfA X-IronPort-AV: E=Sophos;i="4.75,663,1330923600"; d="scan'208,217";a="308215946" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 May 2012 17:21:01 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 May 2012 17:20:42 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sat, 26 May 2012 17:22:55 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "dispatch@ietf.org" Date: Sat, 26 May 2012 17:22:56 -0400 Thread-Topic: Conference Focus Indicating CCMP Support draft Thread-Index: AQHNO4W32cMy6a3UFk6RCU1gBR6sSA== Message-ID: <6369CB70BFD88942B9705AC1E639A338231294492E@DC-US1MBEX4.global.avaya.com> 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_6369CB70BFD88942B9705AC1E639A338231294492EDCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [dispatch] Conference Focus Indicating CCMP Support draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 21:23:00 -0000 --_000_6369CB70BFD88942B9705AC1E639A338231294492EDCUS1MBEX4glo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Mary and I have submitted the following new draft: https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/ The draft defines a way that enables a client to discover if a conference f= ocus supports CCMP. The draft discusses several options and recommends two of these options, de= pending on the need of the client. The draft is based on another draft that we submitted to XCON, https://data= tracker.ietf.org/doc/draft-yusef-xcon-ccmp-indication/,but because XCON is = closed we are coming back to DISPATCH. We are looking to progress this document as an AD sponsored document. We would appreciate it if people review the document and provide us with th= eir feedback. Thanks, Rifaat --_000_6369CB70BFD88942B9705AC1E639A338231294492EDCUS1MBEX4glo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Mary and I have submitted the following new draft:
https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indicati= on/


The draft defines a way that enables a client to discover if a conference f= ocus supports CCMP.
The draft discusses several options and recommends two of these options, de= pending on the need of the client.
The draft is based on another draft that we submitted to XCON, https://data= tracker.ietf.org/doc/draft-yusef-xcon-ccmp-indication/,but because XCON is = closed we are coming back to DISPATCH.

We are looking to progress this document as an AD sponsored document.

We would appreciate it if people review the document and provide us with th= eir feedback.

Thanks,
Rifaat

--_000_6369CB70BFD88942B9705AC1E639A338231294492EDCUS1MBEX4glo_-- From gonzalo.camarillo@ericsson.com Mon May 28 03:45:53 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1194C21F84D5 for ; Mon, 28 May 2012 03:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aadD4ZnfiB1c for ; Mon, 28 May 2012 03:45:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54C21F8476 for ; Mon, 28 May 2012 03:45:51 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-f2-4fc3575dcb34 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0B.5B.11869.D5753CF4; Mon, 28 May 2012 12:45:50 +0200 (CEST) Received: from [131.160.36.95] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Mon, 28 May 2012 12:45:49 +0200 Message-ID: <4FC3575D.1030202@ericsson.com> Date: Mon, 28 May 2012 13:45:49 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John-Luc Bakker References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrW5c+GF/gyVneSyWTlrAavHnYCuL A5PHkiU/mTwmfFnJEsAUxWWTkpqTWZZapG+XwJXx8MYpxoL/4RVrf05nbGC85NHFyMkhIWAi senvZzYIW0ziwr31QDYXh5DAKUaJ3sPzWSGc1YwS09pvMYJU8QpoS2w//Q6sg0VAVeJn+3l2 EJtNwEJiy637LCC2qECwxLzumywQ9YISJ2c+AbNFgOofLj0GNocZaM7/6+vAbGEBe4mHV/+y gthCAm+YJD5P0gaxOQXcJe62/GSBuE5S4uC/a+wQvXoSU662QM2Rl9j+dg4zRK+2xPJnLSwT GIVmIVk9C0nLLCQtCxiZVzEK5yZm5qSXG+mlFmUmFxfn5+kVp25iBAbxwS2/VXcw3jkncohR moNFSZzXeusefyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M/mK7LdxeH2pKWhO7aol366ua PlbDZ1F9f+wfLSk1Wrpl1nyGlGTfVytOfBUQqTp0MZuz3+WY75yLXHnBoQ8k1SS2fXpRJe2l f3325x1Sr464qh8y9lp/Ue2+0+yb1y7X7rh8WfeC1VLWh6stnPV7W+cyfXj5/2KhqsYORoeG TMP4C9vvaaYqKLEUZyQaajEXFScCAOs6VK0wAgAA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 10:45:53 -0000 Hi John Luc, checking the history of this draft, there were some discussions around a late IPR disclosure some time ago: http://www.ietf.org/mail-archive/web/ietf/current/msg59428.html Was there any conclusion? Thanks, Gonzalo On 16/05/2012 1:37 AM, John-Luc Bakker wrote: > Hi, > > Thanks for reviewing the draft. > Please see inline. > > Kind regards, > > John-Luc > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Wednesday, April 18, 2012 6:08 AM > To: John-Luc Bakker > Cc: Paul Kyzivat; dispatch@ietf.org > Subject: Re: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 > > Hi John Luc, > > it is important that the DISPATCH community understands how you would like to progress this draft so that they provide their input. Per RFC 2183, the registration of disposition types requires a Standards Track or an IESG-Approved Experimental RFC: > > http://www.iana.org/assignments/mail-cont-disp/mail-cont-disp.xml#mail-cont-disp-1 > > You draft seems to aim to become an Experimental RFC, right? > > JL: Yes, that is the intention. > > I guess the reasons for this RFC to be Experimental are given in Section > 1 of the draft, right? > > http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling-08#section-1 > > JL: Yes. > > I assume you considered Section 8 of RFC 5621 when deciding disposition types were the right tool for what you need to do: > > http://www.iana.org/assignments/media-types/application/3gpp-ims+xml > > JL: Yes. And in addition, the ' 3GPP IM CN Subsystem XML body' has been around longer than RF 5621. > > Thanks, > > Gonzalo > > > On 09/04/2012 5:47 PM, John-Luc Bakker wrote: >> Dear Paul, Gonzalo, >> >> I received an editorial comment on this draft. The draft is referring to sections 2.2, 2.3 and 2.1. These references should have been 4.2.1, 4.2.2 and 4.2.3. >> >> Have you had an oppertunity to further digest the draft in light of our previous offline discussion? >> >> Kind regards, >> >> John-Luc >> >> -----Original Message----- >> From: John-Luc Bakker >> Sent: Tuesday, March 27, 2012 12:37 PM >> To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com >> Cc: dispatch@ietf.org >> Subject: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: >> [dispatch] I-D Action: >> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) >> >> Dear all, >> >> I have just made revision 8 of draft-bakker-sipping-3gpp-ims-xml-body-handling available following offline discussion. Biggest addition is the new section 2.1 which aims to further motivate the need for the ID. >> >> You can find the HTML formatted version here: >> http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-hand >> ling-08 >> >> I am looking forward to hearing about any concerns you may have. >> >> Kind regards, >> >> John-Luc >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of John-Luc Bakker >> Sent: Tuesday, March 20, 2012 1:53 PM >> To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com >> Cc: dispatch@ietf.org; sipping >> Subject: Re: [dispatch] I-D Action: >> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >> >> Hi, >> >> Thanks, Paul for reviewing the draft. >> Appologies for having delayed this response. >> >> Let me address first the question about this being a SIPPING draft: I intend to ask Gonzallo to sponsor this draft. To collect any further comments and ensure visibility (sine the sipping list is obsolete), I have copied the DISPATCH list. >> >> See also inline with . >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Saturday, December 03, 2011 12:11 PM >> To: John-Luc Bakker >> Cc: sipping >> Subject: Re: I-D Action: >> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >> >> I'm commenting on this on the (now obsolete) sipping list because this >> has sipping in its name. This may not be the best place. I suppose an >> alternative is rai. >> >> ISTM that there are three degrees of freedom here for identifying how >> to process these bodies: >> - content-disposition >> - content-type >> - the actual content of the body >> >> Of these, the content-disposition is the most heavy weight in terms of >> mechanism, while the actual content of the body is the least heavy-weight. >> >> So, I wonder why you have chosen to use one content-type, that seems >> to already contain distinct representations for the differing >> behaviors of interest, and yet use distinct content-dispositions. I >> think you could use a single content-disposition and get the same effect. >> >> I guess multiple content-dispositions might make sense if they are >> processed by different entities, so that only the intended entities >> need decode the body. >> >> The reason for having two content dispositions is because there are different behaviors for the same content-type when received by different entities. >> There are two different entities that apply a different behavior when receiving the body, say behavior A and behavior B. However, XML elements present in the body trigger behavior A (in the abstract of the draft, behavior (2)) by entity A and if not present, no further behavior by entity A is specified in this draft. Other XML elements present in the body trigger one of a set of behaviors B (in the abstract of the draft, behaviors (1) and (3)) by entity B and if not present, no further behavior by entity B is specified in this draft. >> >> It would also make sense if the same identical body representation was >> processed differently based on the content-disposition. >> >> The bodies triggering the different behaviors are indeed not identical. >> However, the content-dispositions are processed by different entities, which is a reason for proposing these content-disposition values. >> >> But I don't think either of those is the case here. So I would find it helpful if this draft explained why it chooses to use multiple content-dispositions. >> >> The draft illustrates that, in IMS, different entities receive bodies with the content-type, and apply different behaviors. The draft further suggests that the applicability of these values may be limited to IMS. Do you see a need for a general discussion of this approach since the applicability is limited to IMS? >> >> I also think it would be useful to say something about how you expect >> the handling parameter to be used with these dispositions. If >> handling=required (the default) is used, then any UA that gets this >> must fail the request unless it is able to handle the body. If >> handling=optional is specified, then that need not be so. >> >> The handling parameter is mentioned in RFC 3261 and this draft refers to that RFC. RFC 3261 refers to RFC 3204. This draft does not change the behavior and interpretation of the parameter and its values. It should not be necessary to repeat what has already been documented in RFC 3261. Do you see different behavior that goes beyond what has been documented? >> >> Thanks, >> Paul >> >> On 12/3/11 5:08 AM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> Title : Specification of 3GPP IM CN Subsystem XML body handling >>> Author(s) : John-Luc Bakker >>> Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >>> Pages : 7 >>> Date : 2011-12-02 >>> >>> This document registers new disposition-types for the Content- >>> Disposition header field that apply to the application/3gpp-ims+xml >>> body used by 3GPP. The applicability of these content-disposition >>> values are limited to 3GPP IMS. The application/3gpp-ims+xml body >>> has the following three distinct uses: (1) for redirecting the >>> emergency session to use a different domain (e.g. using a Circuit >>> Switched call), (2) for delivering user profile specific information >>> from the SIP registrar to an Application Server, and (3) for causing >>> a UAC to attempt to re-register with the IMS. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml >>> -body-handling-07.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml- >>> body-handling-07.txt >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > From gonzalo.camarillo@ericsson.com Wed May 30 01:18:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A1921F86FC for ; Wed, 30 May 2012 01:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.309 X-Spam-Level: X-Spam-Status: No, score=-106.309 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2DDZ-kclb7E for ; Wed, 30 May 2012 01:18:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C68C121F86F7 for ; Wed, 30 May 2012 01:18:38 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-d6-4fc5d7dd6288 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CF.7B.11869.DD7D5CF4; Wed, 30 May 2012 10:18:37 +0200 (CEST) Received: from [131.160.36.95] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Wed, 30 May 2012 10:18:36 +0200 Message-ID: <4FC5D7DC.3050809@ericsson.com> Date: Wed, 30 May 2012 11:18:36 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John-Luc Bakker References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <4FC3575D.1030202@ericsson.com> In-Reply-To: <4FC3575D.1030202@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvre7d60f9DZZ9E7dYOmkBq8Wfg60s DkweS5b8ZPKY8GUlSwBTFJdNSmpOZllqkb5dAlfGn0/L2Au+xVfsPrWfrYHxpH8XIyeHhICJ xLrmmewQtpjEhXvr2boYuTiEBE4xSrSvec8M4axmlLj6egkTSBWvgLbEzAsPwGwWAVWJ9j93 WEBsNgELiS237oPZogLBEvO6b7JA1AtKnJz5BMwWAap/uPQYI4jNDDTn//V1YLawgJfE27vt UJt7mCVuHZ0MdhKngI7E5VNtbBDnSUoc/HeNHaJZT2LK1RaoQfIS29/OYQaxhYCGLn/WwjKB UWgWkt2zkLTMQtKygJF5FaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYBgf3PJbdQfjnXMihxil OViUxHmtt+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC44WL3fuZPDV/fvxJYXl7ydc/7 RWpWuRH8xde2xCof2nJutdr32K82VQo/f08NM1JdX2d9mzN3lX/h5W9PbeaUPPxVu4vVr3r3 iXcLo6sCNm7bdyA/4rLYt5q9peKZEfuq/GTnzKwJWKGkuONvkffizdtmH9eR3tdR6V4eMYkx vTn/dybzLO4SJZbijERDLeai4kQArZrw/zECAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 08:18:41 -0000 Hi John Luc, an additional clarifying question on this draft. What the draft proposes to do with three new disposition types, could also be done with three different media types, which could be registered in the vendor tree. In fact, all registrations under Meredith expect the one related to this draft are in the vendor tree: http://www.iana.org/assignments/media-types/application/index.html Registering media types in the vendor tree is straight forward: http://tools.ietf.org/html/rfc4288#section-3.2 Have you considered such an approach at all? Thanks, Gonzalo On 28/05/2012 1:45 PM, Gonzalo Camarillo wrote: > Hi John Luc, > > checking the history of this draft, there were some discussions around a > late IPR disclosure some time ago: > > http://www.ietf.org/mail-archive/web/ietf/current/msg59428.html > > Was there any conclusion? > > Thanks, > > Gonzalo > > On 16/05/2012 1:37 AM, John-Luc Bakker wrote: >> Hi, >> >> Thanks for reviewing the draft. >> Please see inline. >> >> Kind regards, >> >> John-Luc >> >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Wednesday, April 18, 2012 6:08 AM >> To: John-Luc Bakker >> Cc: Paul Kyzivat; dispatch@ietf.org >> Subject: Re: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 >> >> Hi John Luc, >> >> it is important that the DISPATCH community understands how you would like to progress this draft so that they provide their input. Per RFC 2183, the registration of disposition types requires a Standards Track or an IESG-Approved Experimental RFC: >> >> http://www.iana.org/assignments/mail-cont-disp/mail-cont-disp.xml#mail-cont-disp-1 >> >> You draft seems to aim to become an Experimental RFC, right? >> >> JL: Yes, that is the intention. >> >> I guess the reasons for this RFC to be Experimental are given in Section >> 1 of the draft, right? >> >> http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling-08#section-1 >> >> JL: Yes. >> >> I assume you considered Section 8 of RFC 5621 when deciding disposition types were the right tool for what you need to do: >> >> http://www.iana.org/assignments/media-types/application/3gpp-ims+xml >> >> JL: Yes. And in addition, the ' 3GPP IM CN Subsystem XML body' has been around longer than RF 5621. >> >> Thanks, >> >> Gonzalo >> >> >> On 09/04/2012 5:47 PM, John-Luc Bakker wrote: >>> Dear Paul, Gonzalo, >>> >>> I received an editorial comment on this draft. The draft is referring to sections 2.2, 2.3 and 2.1. These references should have been 4.2.1, 4.2.2 and 4.2.3. >>> >>> Have you had an oppertunity to further digest the draft in light of our previous offline discussion? >>> >>> Kind regards, >>> >>> John-Luc >>> >>> -----Original Message----- >>> From: John-Luc Bakker >>> Sent: Tuesday, March 27, 2012 12:37 PM >>> To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com >>> Cc: dispatch@ietf.org >>> Subject: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: >>> [dispatch] I-D Action: >>> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) >>> >>> Dear all, >>> >>> I have just made revision 8 of draft-bakker-sipping-3gpp-ims-xml-body-handling available following offline discussion. Biggest addition is the new section 2.1 which aims to further motivate the need for the ID. >>> >>> You can find the HTML formatted version here: >>> http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-hand >>> ling-08 >>> >>> I am looking forward to hearing about any concerns you may have. >>> >>> Kind regards, >>> >>> John-Luc >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of John-Luc Bakker >>> Sent: Tuesday, March 20, 2012 1:53 PM >>> To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com >>> Cc: dispatch@ietf.org; sipping >>> Subject: Re: [dispatch] I-D Action: >>> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >>> >>> Hi, >>> >>> Thanks, Paul for reviewing the draft. >>> Appologies for having delayed this response. >>> >>> Let me address first the question about this being a SIPPING draft: I intend to ask Gonzallo to sponsor this draft. To collect any further comments and ensure visibility (sine the sipping list is obsolete), I have copied the DISPATCH list. >>> >>> See also inline with . >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Saturday, December 03, 2011 12:11 PM >>> To: John-Luc Bakker >>> Cc: sipping >>> Subject: Re: I-D Action: >>> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >>> >>> I'm commenting on this on the (now obsolete) sipping list because this >>> has sipping in its name. This may not be the best place. I suppose an >>> alternative is rai. >>> >>> ISTM that there are three degrees of freedom here for identifying how >>> to process these bodies: >>> - content-disposition >>> - content-type >>> - the actual content of the body >>> >>> Of these, the content-disposition is the most heavy weight in terms of >>> mechanism, while the actual content of the body is the least heavy-weight. >>> >>> So, I wonder why you have chosen to use one content-type, that seems >>> to already contain distinct representations for the differing >>> behaviors of interest, and yet use distinct content-dispositions. I >>> think you could use a single content-disposition and get the same effect. >>> >>> I guess multiple content-dispositions might make sense if they are >>> processed by different entities, so that only the intended entities >>> need decode the body. >>> >>> The reason for having two content dispositions is because there are different behaviors for the same content-type when received by different entities. >>> There are two different entities that apply a different behavior when receiving the body, say behavior A and behavior B. However, XML elements present in the body trigger behavior A (in the abstract of the draft, behavior (2)) by entity A and if not present, no further behavior by entity A is specified in this draft. Other XML elements present in the body trigger one of a set of behaviors B (in the abstract of the draft, behaviors (1) and (3)) by entity B and if not present, no further behavior by entity B is specified in this draft. >>> >>> It would also make sense if the same identical body representation was >>> processed differently based on the content-disposition. >>> >>> The bodies triggering the different behaviors are indeed not identical. >>> However, the content-dispositions are processed by different entities, which is a reason for proposing these content-disposition values. >>> >>> But I don't think either of those is the case here. So I would find it helpful if this draft explained why it chooses to use multiple content-dispositions. >>> >>> The draft illustrates that, in IMS, different entities receive bodies with the content-type, and apply different behaviors. The draft further suggests that the applicability of these values may be limited to IMS. Do you see a need for a general discussion of this approach since the applicability is limited to IMS? >>> >>> I also think it would be useful to say something about how you expect >>> the handling parameter to be used with these dispositions. If >>> handling=required (the default) is used, then any UA that gets this >>> must fail the request unless it is able to handle the body. If >>> handling=optional is specified, then that need not be so. >>> >>> The handling parameter is mentioned in RFC 3261 and this draft refers to that RFC. RFC 3261 refers to RFC 3204. This draft does not change the behavior and interpretation of the parameter and its values. It should not be necessary to repeat what has already been documented in RFC 3261. Do you see different behavior that goes beyond what has been documented? >>> >>> Thanks, >>> Paul >>> >>> On 12/3/11 5:08 AM, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> Title : Specification of 3GPP IM CN Subsystem XML body handling >>>> Author(s) : John-Luc Bakker >>>> Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt >>>> Pages : 7 >>>> Date : 2011-12-02 >>>> >>>> This document registers new disposition-types for the Content- >>>> Disposition header field that apply to the application/3gpp-ims+xml >>>> body used by 3GPP. The applicability of these content-disposition >>>> values are limited to 3GPP IMS. The application/3gpp-ims+xml body >>>> has the following three distinct uses: (1) for redirecting the >>>> emergency session to use a different domain (e.g. using a Circuit >>>> Switched call), (2) for delivering user profile specific information >>>> from the SIP registrar to an Application Server, and (3) for causing >>>> a UAC to attempt to re-register with the IMS. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml >>>> -body-handling-07.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml- >>>> body-handling-07.txt >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From fluffy@iii.ca Thu May 31 06:21:47 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D0421F8650 for ; Thu, 31 May 2012 06:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCvnm3z+KOxg for ; Thu, 31 May 2012 06:21:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6151521F864C for ; Thu, 31 May 2012 06:21:45 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6019622DD6D; Thu, 31 May 2012 09:21:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> Date: Thu, 31 May 2012 07:21:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> To: John-Luc Bakker X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:21:47 -0000 On May 15, 2012, at 4:37 PM, John-Luc Bakker wrote: > JL: Yes, that is the intention. >=20 > I guess the reasons for this RFC to be Experimental are given in = Section > 1 of the draft, right? >=20 > = http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling= -08#section-1 I think something intended to be production deployed on the order of a = billion devices on the internet is not appropriate to be called = "experimental" From fluffy@iii.ca Thu May 31 06:40:46 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0740621F8666 for ; Thu, 31 May 2012 06:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKMpmt3ot8Z4 for ; Thu, 31 May 2012 06:40:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 707B421F842B for ; Thu, 31 May 2012 06:40:45 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 78F4922E25C; Thu, 31 May 2012 09:40:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4FC3575D.1030202@ericsson.com> Date: Thu, 31 May 2012 07:40:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <4FC3575D.1030202@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:40:46 -0000 On May 28, 2012, at 4:45 AM, Gonzalo Camarillo wrote: > Hi John Luc, >=20 > checking the history of this draft, there were some discussions around = a > late IPR disclosure some time ago: >=20 > http://www.ietf.org/mail-archive/web/ietf/current/msg59428.html >=20 > Was there any conclusion? >=20 > Thanks, Just to be very clear, sending this with my individual contributor hat = on here ... My recollection was there was some discussion of ways to solve this = problem that would avoid the IPR disclosed. Some people expressed = concerns with that which led to some discussion that indicated it was = not 100% clear to everyone what the problem being solved was. No = conclusion was ever made on which way to proposed. John-Luc, does that = roughly match what you remember? Thanks, Cullen From fluffy@iii.ca Thu May 31 07:01:53 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B0921F8627 for ; Thu, 31 May 2012 07:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d6IgWJivTp3 for ; Thu, 31 May 2012 07:01:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4BD21F8587 for ; Thu, 31 May 2012 07:01:51 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF4A922E25C; Thu, 31 May 2012 10:01:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <6369CB70BFD88942B9705AC1E639A338231294492E@DC-US1MBEX4.global.avaya.com> Date: Thu, 31 May 2012 08:01:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <30867AE3-83E0-4AB2-BA34-8E4E684D4901@iii.ca> References: <6369CB70BFD88942B9705AC1E639A338231294492E@DC-US1MBEX4.global.avaya.com> To: "Shekh-Yusef, Rifaat (Rifaat)" X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Conference Focus Indicating CCMP Support draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:01:53 -0000 I read the draft and I like it - both approach look like they should = work OK.=20 The feature tags approach makes sense to me and I seems like the right = way to do this. I could live with the service URI approach. I certainly = don't want both :-)=20 Anyways, my 2 cents would be to see what others say and see if you can = get consensus around pursuing the feature tag / Call Info approach. The = extra options message to conf server seems like a drop in the bucket on = the messaging involved with an XCON conference.=20 Cullen On May 26, 2012, at 3:22 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, >=20 > Mary and I have submitted the following new draft: > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/ >=20 > The draft defines a way that enables a client to discover if a = conference focus supports CCMP. > The draft discusses several options and recommends two of these = options, depending on the need of the client. > The draft is based on another draft that we submitted to XCON, = https://datatracker.ietf.org/doc/draft-yusef-xcon-ccmp-indication/,but = because XCON is closed we are coming back to DISPATCH. >=20 > We are looking to progress this document as an AD sponsored document. >=20 > We would appreciate it if people review the document and provide us = with their feedback. >=20 > Thanks, > Rifaat > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Thu May 31 07:11:01 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B33721F869A for ; Thu, 31 May 2012 07:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xU5N+Qqh3Ix for ; Thu, 31 May 2012 07:10:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C94D921F8692 for ; Thu, 31 May 2012 07:10:59 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C920B22E256; Thu, 31 May 2012 10:10:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BD10A648@HKGMBOXPRD22.polycom.com> Date: Thu, 31 May 2012 08:10:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <68293E00-E2C8-4290-A670-69886B24E96F@iii.ca> References: <20120327195440.23510.16538.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA3516736B@XMB104ADS.rim.net> <520B9CDF-84EA-45B2-9479-518056F8BAFC@edvina.net> <1F2A2C70609D9E41844A2126145FC09804BD10A648@HKGMBOXPRD22.polycom.com> To: "Avasarala, Ranjit" X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:11:01 -0000 It's more than just the abstract - the draft clearly says this is not = for internet. Given the CDIV is a widely deployed feature, I think = anything the IETF publishes for this should be generally applicable for = any SIP device. I can't see anything in here that would cause this to = only work on IMS / TISPAN. Could all mention of that be removed from the = draft and it just defined as a general service? On May 16, 2012, at 3:24 AM, Avasarala, Ranjit wrote: > Hi Oile >=20 > Though the abstract of the draft mentions 3GPP and IMS, the CDIVN = service and the proposed event package holds good for any SIP based VoIP = networks. So you could look at it as a generic SIP based event = notification and event package conforming to RFC 3265.=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Olle E. Johansson > Sent: Wednesday, May 09, 2012 7:48 PM > To: John-Luc Bakker > Cc: dispatch@ietf.org > Subject: Re: [dispatch] comments requested for = draft-avasarala-dispatch-comm-div-notification-09 >=20 >=20 > 9 maj 2012 kl. 15:38 skrev John-Luc Bakker: >=20 >> Hi, >>=20 >> I like to announce the availability of the draft below.=20 >> Comments received during previous reviews have been addressed. >=20 > While reading this for the first time I find it strange that this is = only aimed at the 3GPP application world. >=20 > I see many cases where I have network-controlled call forwarding and = want all phones registred to my AOR to get information that the AOR is = forwarded. >=20 > Ideally I would like the SIP phone manufacturers to have their phones = subscribe to this package. >=20 > Now if I press a DND button on my phone - will i PUBLISH an XML = document to update my status in the server and enable a service? The = draft does not mention anything about PUBLISH. >=20 > /O > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From prvs=5498309e7c=aallen@rim.com Thu May 31 08:50:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77AD11E8102 for ; Thu, 31 May 2012 08:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU5sWgzrk1Bw for ; Thu, 31 May 2012 08:50:21 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 361DC21F8714 for ; Thu, 31 May 2012 08:50:21 -0700 (PDT) X-AuditID: 0a41282f-b7f526d0000063ec-ed-4fc7933c131d Received: from XCT104CNC.rim.net (xct104cnc.rim.net [10.65.161.204]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 88.45.25580.C3397CF4; Thu, 31 May 2012 15:50:20 +0000 (GMT) Received: from XCT109CNC.rim.net (10.65.161.209) by XCT104CNC.rim.net (10.65.161.204) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 31 May 2012 11:50:19 -0400 Received: from XCT101ADS.rim.net (10.67.111.42) by XCT109CNC.rim.net (10.65.161.209) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 31 May 2012 11:50:19 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.01.0339.001; Thu, 31 May 2012 10:50:18 -0500 From: Andrew Allen To: Cullen Jennings , John-Luc Bakker Thread-Topic: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Thread-Index: AQHNMutQ9uHTWKQ4l02PV8DQbcH7QJbkTpYA///HeZA= Date: Thu, 31 May 2012 15:50:17 +0000 Message-ID: References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> In-Reply-To: <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKKsWRmVeSWpSXmKPExsXC5bjwjK7N5OP+Bn8mCFuc3zSH0WLppAWs Fh/W/2B0YPb49fUqm8eSJT+ZPC6f/8gYwBzVwGiTlFhSFpyZnqdvZ5OYl5dfkliSqpCSWpxs q+STmp6YoxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2KrlFhQkJqXomTH pYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HQTOnkyzk75yV7wRqziQNdTpgbGA0Jd jJwcEgImEv9bFrJA2GISF+6tZ+ti5OIQEuhjktg//TILhLOSUWL5u33sEM4KRonGjwehyrYw SpxcuY4ZpJ9NQFli+e8ZjCC2iICbxPOGh2BxZoEUiaOrvrCB2MICXhKrv7VA1XhLnNg5G8q2 knj78DMTiM0ioCrx6fZVoHoODl6gORPn1EItZpbYcrkTrJ4TqP7O5A1g8xkFZCV2n73OBLFL XOLWk/lMEP8ISCzZc54ZwhaVePn4HyuErSjxuKWbBaJeR2LB7k9sELa2xLKFr8HqeQUEJU7O fAJWIyQgLbHj5BrGCYySs5CsmIWkfRaS9llI2hcwsqxiFMzNKDYwM0jOS9YryszVy0st2cQI TkQa+jsY+/ZqHWIU4GBU4uFtaDnuL8SaWFZcmXuIUYKDWUmEd3sJUIg3JbGyKrUoP76oNCe1 +BCjBTCEJjJLcSfnA5NkXkm8sYEBCkdJnPfClz3+QgLpwESWnZpakFoE08rEwQkymktKpBiY jlKLEktLMuJBSTO+GJg2pRoYNzx+dnvNqp/aJ8IjLLOSHErlG9+/Twv9f3BGx8+Ax0ePNOht k2e4ktxguzCy3TuWVzdpwaXu4uWaMVt7L0xe/jFk8SqmWv2Mos99cw5PTlR+u3Z5/cEP6rJX NI3ZDyd7i6j1CcXK3vdzFLz65OmH6OUnataVRd2t6NvGPcdSQOihdETVIc0mJZbijERDLeai 4kQAdhf/N3gDAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:50:23 -0000 Cullen Do you include 3GPP IMS as part of the internet now? I thought at least some= people in IETF regarded it as a "walled garden". My understanding is that the scope of this is for 3GPP IMS usage only and sp= ecifically related to 3GPP IMS emergency calls and 3GPP IMS fault recovery p= rocedures. This 3GPP specific XML body and the associated procedures are ver= y specific to 3GPP IMS and not generally applicable to the internet. I thought it was decided a long time ago that not every 3GPP IMS specific th= ing needed to be standards track. Hence P-headers (e.g RFC 3455,.....), and= now expert reviews for many things that are needed to meet 3GPP special req= uirements. Such things which are not standards track will also be deployed i= n the same billion devices. So I don't think the potential number of devices= that functionality will be deployed in is a criteria for determining whethe= r that functionality should be standards track or not. My understanding was that RAI area was trying to move away from WGs spending= a lot of energy working on 3GPP specific things that were not generally app= licable (not the other way around) hence the move to expert reviews for some= things that used to require work in SIPPING. RFC 3113 defines cooperation between 3GPP and IETF. I don't think it is real= ly in the spirit of this agreement that over 4 years after the initial draft= submission suggestions are just now being made that this should be standard= s track. Lack of progression of this draft (and some others) is having a negative imp= act on the deployment of the billion devices. An entire industry cannot tole= rate continuing delay. I fear that if we cannot soon progress these drafts t= o RFC status we will very soon end up in a situation that a billion devices= will be deployed with types and identifiers that are not IANA registered an= d that cannot be good for 3GPP or the internet. Andrew > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Thursday, May 31, 2012 8:22 AM > To: John-Luc Bakker > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling- > 07 > > > On May 15, 2012, at 4:37 PM, John-Luc Bakker wrote: > > > JL: Yes, that is the intention. > > > > I guess the reasons for this RFC to be Experimental are given in > Section > > 1 of the draft, right? > > > > http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body- > handling-08#section-1 > > I think something intended to be production deployed on the order of a > billion devices on the internet is not appropriate to be called > "experimental" > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From adam@nostrum.com Thu May 31 09:34:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF111E80AF for ; Thu, 31 May 2012 09:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.6 X-Spam-Level: X-Spam-Status: No, score=-103.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jeaxx0v5wG4s for ; Thu, 31 May 2012 09:34:37 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9240B11E8096 for ; Thu, 31 May 2012 09:34:37 -0700 (PDT) Received: from Hydra.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VGYZsN086157 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 31 May 2012 11:34:35 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4FC79D9B.20902@nostrum.com> Date: Thu, 31 May 2012 11:34:35 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050308060302000006070609" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:34:41 -0000 This is a multi-part message in MIME format. --------------050308060302000006070609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/31/12 10:50, May 31, Andrew Allen wrote: > Do you include 3GPP IMS as part of the internet now? I thought at least some people in IETF regarded it as a "walled garden". Indulge me as I pass along a joke. A newly convicted inmate shows up at prison on his first day. During lunch, he noticed that a man would shout out a number--"a hundred and twelve" or "thirteen" or "seventy-eight"--and the whole room would burst out in peals of laughter. Perplexed, the new prisoner asked one of his colleagues what everybody was laughing about. "Jokes," the old prisoner said. "We've heard the same jokes so many times that we know them all by heart. In fact, we've heard them so many times that given each of them a number. So instead of telling each other the jokes, we just call out the number to the joke we want to tell. Saves a lot of time." Eager to fit in, the new inmate waited for a pause in the conversations around him and yelled, "Forty-six!" Everybody stopped and stared. Nobody laughed. Near the corner of the table, the man heard one prisoner say to another, "Some guys don't know how to tell a joke." Anyway, as much as I'd like to just say "thirty-seven" and get it over with, we've not quite progressed to this point in RAI. But we're getting close. So the shorthand I'm going to use is "anything you do in a walled garden will eventually leak out into the public Internet." If you want the long form of this argument, it exists in various IETF mailing list archives many times over. > I thought it was decided a long time ago that not every 3GPP IMS specific thing needed to be standards track. Hence P-headers (e.g RFC 3455,.....), and now expert reviews for many things that are needed to meet 3GPP special requirements. You're slightly correct. There is no carte blanche loophole that allows external SDOs to make arbitrary changes to SIP's overall processing. The actual policy, documented in RFC 5727, is that such extensions are okay as long as they meet certain criteria. The addition of new header fields, like those you discuss above, is allowed outside of standards track documents as long as they are "of a purely informational nature and [do] NOT significantly change the behavior of SIP entities that support [them]." I think something as profound as new behavior that redirects clients to use a completely different mode of communication falls way, way outside the spirit and letter of what is allowed by this process. I think that is very much an update to standardized behavior, and as such requires a standards-track specification. > RFC 3113 defines cooperation between 3GPP and IETF. I don't think it is really in the spirit of this agreement that over 4 years after the initial draft submission suggestions are just now being made that this should be standards track. It's a bit specious to claim that any kind of IETF-related work has been going on for that long. As far as I can tell, there have been a grand total of three (!) messages on the SIPPING list on this topic. One, in August of 2008, from John-Luc, announcing the document; another from him in March of 2011, doing the same for the -06 version; and a third, from Paul Kyzivat, in December of 2011. Given that the earliest substantive thing said on this document was five months ago, your "4 year" statistic is way out of line. And, honestly, if you're looking for places where delays exist, you might consider that it took the document author over four months to respond to those comments. On the topic of RFC 3113, I think you'll find that it also has language around 3GPP's use of IETF standards: 3GPP recognizes that additions or modifications might be needed in order to make the IETF internet specification fulfill the needs of 3GPP. In such cases, 3GPP will take its concerns directly to the appropriate IETF working groups for resolution, or to an appropriate Area Director if no appropriate working group can be found. Note that this agreement talks about 3GPP bringing the need for changes to the IETF. Not fully-formed solutions for ratification. When this body handling work showed up at the IETF, it was already specified down to the syntax level. That is never a recipe for success. When it comes to IETF protocols, what *works* is bringing in a *problem*, and then working on a solution together. > Lack of progression of this draft (and some others) is having a negative impact on the deployment of the billion devices. An entire industry cannot tolerate continuing delay. I'm not sure I see how a draft that has generated a sum total of thirteen email messages in its entire existence, a draft that has a four-month turn-around time for responses from its author -- I'm not sure how a draft meeting that description is supposed to be interpreted as urgent. /a --------------050308060302000006070609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/31/12 10:50, May 31, Andrew Allen wrote: 
Do you include 3GPP IMS as part of the internet now? I thought at least some people in IETF regarded it as a "walled garden".

Indulge me as I pass along a joke.

A newly convicted inmate shows up at prison on his first day. During lunch, he noticed that a man would shout out a number–”a hundred and twelve” or “thirteen” or “seventy-eight”–and the whole room would burst out in peals of laughter. Perplexed, the new prisoner asked one of his colleagues what everybody was laughing about. “Jokes,” the old prisoner said. "We've heard the same jokes so many times that we know them all by heart. In fact, we've heard them so many times that given each of them a number. So instead of telling each other the jokes, we just call out the number to the joke we want to tell. Saves a lot of time.”

Eager to fit in, the new inmate waited for a pause in the conversations around him and yelled, “Forty-six!” Everybody stopped and stared. Nobody laughed. Near the corner of the table, the man heard one prisoner say to another, “Some guys don’t know how to tell a joke.”


Anyway, as much as I'd like to just say "thirty-seven" and get it over with, we've not quite progressed to this point in RAI. But we're getting close. So the shorthand I'm going to use is "anything you do in a walled garden will eventually leak out into the public Internet." If you want the long form of this argument, it exists in various IETF mailing list archives many times over.


I thought it was decided a long time ago that not every 3GPP IMS specific thing needed to be standards track. Hence P-headers (e.g RFC 3455,.....), and now expert reviews for many things that are needed to meet 3GPP special requirements.

You're slightly correct. There is no carte blanche loophole that allows external SDOs to make arbitrary changes to SIP's overall processing.

The actual policy, documented in RFC 5727, is that such extensions are okay as long as they meet certain criteria. The addition of new header fields, like those you discuss above, is allowed outside of standards track documents as long as they are "of a purely informational nature and [do] NOT significantly change the behavior of SIP entities that support [them]."

I think something as profound as new behavior that redirects clients to use a completely different mode of communication falls way, way outside the spirit and letter of what is allowed by this process. I think that is very much an update to standardized behavior, and as such requires a standards-track specification.

RFC 3113 defines cooperation between 3GPP and IETF. I don't think it is really in the spirit of this agreement that over 4 years after the initial draft submission suggestions are just now being made that this should be standards track.

It's a bit specious to claim that any kind of IETF-related work has been going on for that long. As far as I can tell, there have been a grand total of three (!) messages on the SIPPING list on this topic. One, in August of 2008, from John-Luc, announcing the document; another from him in March of 2011, doing the same for the -06 version; and a third, from Paul Kyzivat, in December of 2011. Given that the earliest substantive thing said on this document was five months ago, your "4 year" statistic is way out of line. And, honestly, if you're looking for places where delays exist, you might consider that it took the document author over four months to respond to those comments.

On the topic of RFC 3113, I think you'll find that it also has language around 3GPP's use of IETF standards:

   3GPP recognizes that additions or modifications might be
   needed in order to make the IETF internet specification fulfill the
   needs of 3GPP.  In such cases, 3GPP will take its concerns directly
   to the appropriate IETF working groups for resolution, or to an
   appropriate Area Director if no appropriate working group can be
   found.

Note that this agreement talks about 3GPP bringing the need for changes to the IETF. Not fully-formed solutions for ratification. When this body handling work showed up at the IETF, it was already specified down to the syntax level. That is never a recipe for success. When it comes to IETF protocols, what *works* is bringing in a *problem*, and then working on a solution together.

Lack of progression of this draft (and some others) is having a negative impact on the deployment of the billion devices. An entire industry cannot tolerate continuing delay.

I'm not sure I see how a draft that has generated a sum total of thirteen email messages in its entire existence, a draft that has a four-month turn-around time for responses from its author -- I'm not sure how a draft meeting that description is supposed to be interpreted as urgent.

/a
--------------050308060302000006070609-- From michael.hammer@yaanatech.com Thu May 31 10:40:57 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1B911E80C5 for ; Thu, 31 May 2012 10:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSaanGLMuuoa for ; Thu, 31 May 2012 10:40:53 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5A58C11E80A4 for ; Thu, 31 May 2012 10:40:53 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 31 May 2012 10:40:52 -0700 From: Michael Hammer To: "adam@nostrum.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Thread-Index: AQHNHVOLGaoZosgWp06CrMLzAfa1kZbLjn1AgBkM0ACAACmKgIAADGGA//+bX8A= Date: Thu, 31 May 2012 17:40:51 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38B1291@EX2K10MB1.corp.yaanatech.com> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> <4FC79D9B.20902@nostrum.com> In-Reply-To: <4FC79D9B.20902@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.18] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0013_01CD3F32.FE2366A0" MIME-Version: 1.0 Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 17:40:57 -0000 ------=_NextPart_000_0013_01CD3F32.FE2366A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_01CD3F32.FE2366A0" ------=_NextPart_001_0014_01CD3F32.FE2366A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Adam, WRT the 1 billion devices versus the 3 billion phones. The joke that came to mind was the challenge to an assorted group of professions to design the smallest fence that would encircle a herd of sheep. I'll spare you the first few attempts. When it came time for the mathematician, he thought a second then built a fence around himself then said, "I define everything on the other side of the fence to be on the inside." It may be news to some, but mobile devices are the Internet access today. If it is a good idea, it should be adopted for wider Internet use, even if it came from the 3GPP. I'll pass on the moment about the evaluation of the immediate draft. Mike From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, May 31, 2012 12:35 PM To: dispatch@ietf.org Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 On 5/31/12 10:50, May 31, Andrew Allen wrote: Do you include 3GPP IMS as part of the internet now? I thought at least some people in IETF regarded it as a "walled garden". Indulge me as I pass along a joke. A newly convicted inmate shows up at prison on his first day. During lunch, he noticed that a man would shout out a number-"a hundred and twelve" or "thirteen" or "seventy-eight"-and the whole room would burst out in peals of laughter. Perplexed, the new prisoner asked one of his colleagues what everybody was laughing about. "Jokes," the old prisoner said. "We've heard the same jokes so many times that we know them all by heart. In fact, we've heard them so many times that given each of them a number. So instead of telling each other the jokes, we just call out the number to the joke we want to tell. Saves a lot of time." Eager to fit in, the new inmate waited for a pause in the conversations around him and yelled, "Forty-six!" Everybody stopped and stared. Nobody laughed. Near the corner of the table, the man heard one prisoner say to another, "Some guys don't know how to tell a joke." Anyway, as much as I'd like to just say "thirty-seven" and get it over with, we've not quite progressed to this point in RAI. But we're getting close. So the shorthand I'm going to use is "anything you do in a walled garden will eventually leak out into the public Internet." If you want the long form of this argument, it exists in various IETF mailing list archives many times over. I thought it was decided a long time ago that not every 3GPP IMS specific thing needed to be standards track. Hence P-headers (e.g RFC 3455,.....), and now expert reviews for many things that are needed to meet 3GPP special requirements. You're slightly correct. There is no carte blanche loophole that allows external SDOs to make arbitrary changes to SIP's overall processing. The actual policy, documented in RFC 5727, is that such extensions are okay as long as they meet certain criteria. The addition of new header fields, like those you discuss above, is allowed outside of standards track documents as long as they are "of a purely informational nature and [do] NOT significantly change the behavior of SIP entities that support [them]." I think something as profound as new behavior that redirects clients to use a completely different mode of communication falls way, way outside the spirit and letter of what is allowed by this process. I think that is very much an update to standardized behavior, and as such requires a standards-track specification. RFC 3113 defines cooperation between 3GPP and IETF. I don't think it is really in the spirit of this agreement that over 4 years after the initial draft submission suggestions are just now being made that this should be standards track. It's a bit specious to claim that any kind of IETF-related work has been going on for that long. As far as I can tell, there have been a grand total of three (!) messages on the SIPPING list on this topic. One, in August of 2008, from John-Luc, announcing the document; another from him in March of 2011, doing the same for the -06 version; and a third, from Paul Kyzivat, in December of 2011. Given that the earliest substantive thing said on this document was five months ago, your "4 year" statistic is way out of line. And, honestly, if you're looking for places where delays exist, you might consider that it took the document author over four months to respond to those comments. On the topic of RFC 3113, I think you'll find that it also has language around 3GPP's use of IETF standards: 3GPP recognizes that additions or modifications might be needed in order to make the IETF internet specification fulfill the needs of 3GPP. In such cases, 3GPP will take its concerns directly to the appropriate IETF working groups for resolution, or to an appropriate Area Director if no appropriate working group can be found. Note that this agreement talks about 3GPP bringing the need for changes to the IETF. Not fully-formed solutions for ratification. When this body handling work showed up at the IETF, it was already specified down to the syntax level. That is never a recipe for success. When it comes to IETF protocols, what *works* is bringing in a *problem*, and then working on a solution together. Lack of progression of this draft (and some others) is having a negative impact on the deployment of the billion devices. An entire industry cannot tolerate continuing delay. I'm not sure I see how a draft that has generated a sum total of thirteen email messages in its entire existence, a draft that has a four-month turn-around time for responses from its author -- I'm not sure how a draft meeting that description is supposed to be interpreted as urgent. /a ------=_NextPart_001_0014_01CD3F32.FE2366A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam,

 

WRT the 1 billion devices versus the 3 billion = phones…

 

The joke that came to mind was the challenge to an assorted group of = professions to design the smallest fence that would encircle a herd of = sheep.

I’ll spare you the first few attempts.

When it came time for the mathematician, he thought a second then = built a fence around himself then said, “I define everything on = the other side of the fence to be on the = inside.”

 

It may be news to some, but mobile devices are the Internet access = today.

If it is a good idea, it should be adopted for wider Internet use, = even if it came from the 3GPP.

 

I’ll pass on the moment about the evaluation of the immediate = draft.

 

Mike

 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Adam Roach
Sent: Thursday, May 31, 2012 12:35 = PM
To: dispatch@ietf.org
Subject: Re: [dispatch] = draft-bakker-sipping-3gpp-ims-xml-body-handling-07

<= /div>

 

On 5/31/12 10:50, May 31, Andrew Allen wrote: = 

Do you include 3GPP IMS as part of the internet now? =
I thought at least some people in IETF regarded it as a "walled =
garden".


Indulge me as I pass along a = joke.

A newly convicted inmate shows up at prison on = his first day. During lunch, he noticed that a man would shout out a = number–”a hundred and twelve” or = “thirteen” or “seventy-eight”–and the = whole room would burst out in peals of laughter. Perplexed, the new = prisoner asked one of his colleagues what everybody was laughing about. = “Jokes,” the old prisoner said. "We've heard the same = jokes so many times that we know them all by heart. In fact, we've heard = them so many times that given each of them a number. So instead of = telling each other the jokes, we just call out the number to the joke we = want to tell. Saves a lot of time.”

Eager to fit = in, the new inmate waited for a pause in the conversations around him = and yelled, “Forty-six!” Everybody stopped and stared. = Nobody laughed. Near the corner of the table, the man heard one prisoner = say to another, “Some guys don’t know how to tell a = joke.”


Anyway, as much as = I'd like to just say "thirty-seven" and get it over with, = we've not quite progressed to this point in RAI. But we're getting = close. So the shorthand I'm going to use is "anything you do in a = walled garden will eventually leak out into the public Internet." = If you want the long form of this argument, it exists in various IETF = mailing list archives many times = over.



I thought it was decided a long =
time ago that not every 3GPP IMS specific thing needed to be standards =
track. Hence P-headers (e.g RFC 3455,.....), and now expert reviews for =
many things that are needed to meet 3GPP special =
requirements.


You're slightly = correct. There is no carte blanche loophole that allows external SDOs to = make arbitrary changes to SIP's overall processing.

The actual = policy, documented in RFC 5727, is that such extensions are okay as long = as they meet certain criteria. The addition of new header fields, like = those you discuss above, is allowed outside of standards track documents = as long as they are "of a purely informational nature and [do] NOT = significantly change the behavior of SIP entities that support = [them]."

I think something as profound as new behavior that = redirects clients to use a completely different mode of communication = falls way, way outside the spirit and letter of what is allowed by this = process. I think that is very much an update to standardized behavior, = and as such requires a standards-track = specification.


RFC 3113 defines =
cooperation between 3GPP and IETF. I don't think it is really in the =
spirit of this agreement that over 4 years after the initial draft =
submission suggestions are just now being made that this should be =
standards track.


It's a bit = specious to claim that any kind of IETF-related work has been going on = for that long. As far as I can tell, there have been a grand total of = three (!) messages on the SIPPING list on this topic. One, in August of = 2008, from John-Luc, announcing the document; another from him in March = of 2011, doing the same for the -06 version; and a third, from Paul = Kyzivat, in December of 2011. Given that the earliest substantive thing = said on this document was five months ago, your "4 year" = statistic is way out of line. And, honestly, if you're looking for = places where delays exist, you might consider that it took the document = author over four months to respond to those comments.

On the = topic of RFC 3113, I think you'll find that it also has language around = 3GPP's use of IETF standards:

   3GPP recognizes that = additions or modifications might be
   needed in order to = make the IETF internet specification fulfill the
   needs = of 3GPP.  In such cases, 3GPP will take its concerns = directly
   to the appropriate IETF working groups for = resolution, or to an
   appropriate Area Director if no = appropriate working group can be
   found.

Note that = this agreement talks about 3GPP bringing the need for changes to the = IETF. Not fully-formed solutions for ratification. When this body = handling work showed up at the IETF, it was already specified down to = the syntax level. That is never a recipe for success. When it comes to = IETF protocols, what *works* is bringing in a *problem*, and then = working on a solution together.


Lack of =
progression of this draft (and some others) is having a negative impact =
on the deployment of the billion devices. An entire industry cannot =
tolerate continuing delay.


I'm = not sure I see how a draft that has generated a sum total of thirteen = email messages in its entire existence, a draft that has a four-month = turn-around time for responses from its author -- I'm not sure how a = draft meeting that description is supposed to be interpreted as = urgent.

/a

------=_NextPart_001_0014_01CD3F32.FE2366A0-- ------=_NextPart_000_0013_01CD3F32.FE2366A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUz MTE3NDA1MFowIwYJKoZIhvcNAQkEMRYEFHf17AAbIX52C7OtsNAcglX3N1M0MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAgDbzmMasd+Tr3yw3CUMXyMl8O8x8UfFYCRpyVFEMGphr yOSnIu8a9X3htLu0+WL1bt/N4S4TO8Cjv6AQGIEx2UH9VwdKvGpumr0xgeJiJGBcotD/l7FGaVrz TQ4RRg7C+iaU7WhYo9wyDPvO1zEy1ygITT4A5Qh5yHFoiS0bOgMAAAAAAAA= ------=_NextPart_000_0013_01CD3F32.FE2366A0-- From adam@nostrum.com Thu May 31 11:30:51 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75D21F8559 for ; Thu, 31 May 2012 11:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwlGIM3SYyH7 for ; Thu, 31 May 2012 11:30:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 54C0B21F8564 for ; Thu, 31 May 2012 11:30:49 -0700 (PDT) Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VIUjp5092629 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 31 May 2012 13:30:46 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4FC7B8D5.10004@nostrum.com> Date: Thu, 31 May 2012 13:30:45 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Hammer References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> <4FC79D9B.20902@nostrum.com> <00C069FD01E0324C9FFCADF539701DB38B1291@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38B1291@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------030709020008080903060106" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 18:30:51 -0000 This is a multi-part message in MIME format. --------------030709020008080903060106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/31/12 12:40, May 31, Michael Hammer wrote: > > Adam, > > WRT the 1 billion devices versus the 3 billion phones... > > The joke that came to mind was the challenge to an assorted group of > professions to design the smallest fence that would encircle a herd of > sheep. > > I'll spare you the first few attempts. > > When it came time for the mathematician, he thought a second then > built a fence around himself then said, "I define everything on the > other side of the fence to be on the inside." > > It may be news to some, but mobile devices are the Internet access today. > > If it is a good idea, it should be adopted for wider Internet use, > even if it came from the 3GPP. > Sure, why not. If the problem exists, the solution should be the same everywhere. But that really *does* point away from an experimental solution, and more towards something standards-track. It points away from a "works in my network but maybe not it yours" solution, and towards a "works in the Internet at large" solution. Right? /a --------------030709020008080903060106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/31/12 12:40, May 31, Michael Hammer wrote:

Adam,

 

WRT the 1 billion devices versus the 3 billion phones…

 

The joke that came to mind was the challenge to an assorted group of professions to design the smallest fence that would encircle a herd of sheep.

I’ll spare you the first few attempts.

When it came time for the mathematician, he thought a second then built a fence around himself then said, “I define everything on the other side of the fence to be on the inside.”

 

It may be news to some, but mobile devices are the Internet access today.

If it is a good idea, it should be adopted for wider Internet use, even if it came from the 3GPP.


Sure, why not. If the problem exists, the solution should be the same everywhere.

But that really *does* point away from an experimental solution, and more towards something standards-track.

It points away from a "works in my network but maybe not it yours" solution, and towards a "works in the Internet at large" solution.

Right?

/a
--------------030709020008080903060106-- From michael.hammer@yaanatech.com Thu May 31 12:57:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A005721F86DA for ; Thu, 31 May 2012 12:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voilT2n65RB3 for ; Thu, 31 May 2012 12:57:02 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8250121F86D8 for ; Thu, 31 May 2012 12:57:02 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 31 May 2012 12:57:01 -0700 From: Michael Hammer To: "adam@nostrum.com" Thread-Topic: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Thread-Index: AQHNHVOLGaoZosgWp06CrMLzAfa1kZbLjn1AgBkM0ACAACmKgIAADGGA//+bX8CAAIUWgP//opYg Date: Thu, 31 May 2012 19:57:01 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38B13FD@EX2K10MB1.corp.yaanatech.com> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> <4FC79D9B.20902@nostrum.com> <00C069FD01E0324C9FFCADF539701DB38B1291@EX2K10MB1.corp.yaanatech.com> <4FC7B8D5.10004@nostrum.com> In-Reply-To: <4FC7B8D5.10004@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.18] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01CD3F46.034DBFA0" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:57:03 -0000 ------=_NextPart_000_0055_01CD3F46.034DBFA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0056_01CD3F46.034DBFA0" ------=_NextPart_001_0056_01CD3F46.034DBFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree. Absolutely. Mike From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, May 31, 2012 2:31 PM To: Michael Hammer Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 On 5/31/12 12:40, May 31, Michael Hammer wrote: Adam, WRT the 1 billion devices versus the 3 billion phones. The joke that came to mind was the challenge to an assorted group of professions to design the smallest fence that would encircle a herd of sheep. I'll spare you the first few attempts. When it came time for the mathematician, he thought a second then built a fence around himself then said, "I define everything on the other side of the fence to be on the inside." It may be news to some, but mobile devices are the Internet access today. If it is a good idea, it should be adopted for wider Internet use, even if it came from the 3GPP. Sure, why not. If the problem exists, the solution should be the same everywhere. But that really *does* point away from an experimental solution, and more towards something standards-track. It points away from a "works in my network but maybe not it yours" solution, and towards a "works in the Internet at large" solution. Right? /a ------=_NextPart_001_0056_01CD3F46.034DBFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree.  Absolutely.

 

Mike

 

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Thursday, = May 31, 2012 2:31 PM
To: Michael Hammer
Cc: = dispatch@ietf.org
Subject: Re: [dispatch] = draft-bakker-sipping-3gpp-ims-xml-body-handling-07

<= /div>

 

On 5/31/12 12:40, May 31, Michael Hammer wrote: =

Adam,

 

WRT the 1 billion devices versus the 3 billion = phones…

 

The joke that came to mind was the challenge to an assorted group of = professions to design the smallest fence that would encircle a herd of = sheep.

I’ll spare you the first few attempts.

When it came time for the mathematician, he thought a second then = built a fence around himself then said, “I define everything on = the other side of the fence to be on the = inside.”

 

It may be news to some, but mobile devices are the Internet access = today.

If it is a = good idea, it should be adopted for wider Internet use, even if it came = from the 3GPP.


Sure, why = not. If the problem exists, the solution should be the same = everywhere.

But that really *does* point away from an = experimental solution, and more towards something = standards-track.

It points away from a "works in my network = but maybe not it yours" solution, and towards a "works in the = Internet at large" = solution.

Right?

/a

------=_NextPart_001_0056_01CD3F46.034DBFA0-- ------=_NextPart_000_0055_01CD3F46.034DBFA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUz MTE5NTY1OVowIwYJKoZIhvcNAQkEMRYEFHdvwXKKHkR4kMhjB5ZJPR8k/0/5MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA2PeA8AMQGQoNCFU703JegMOaZM1lau81TGu1TDVz0LAI ab6WJ276QG/CO0G/PPvxtxqyLlwln3ANbaU1w5mpjC0hSe2boalLg4ebceBF6Y5Uk7az6VRTn6aq HyCeX2/T+usu9GOhwgEX2A9+tEYLQBzBdXAKguDhjdV27yEwiFUAAAAAAAA= ------=_NextPart_000_0055_01CD3F46.034DBFA0-- From rifatyu@avaya.com Thu May 31 13:54:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F0E11E8074 for ; Thu, 31 May 2012 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 128cphhaTEYO for ; Thu, 31 May 2012 13:54:27 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4411E8072 for ; Thu, 31 May 2012 13:54:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHbZx0/GmAcF/2dsb2JhbABEtBWBB4IYAQEBAQMBAQEPKC4GCwwEAgEIDQEDBAEBAR4JBycLFAkIAQEEDgUIGodpC5t7nFUEixGEZmADmwmKAoJ8 X-IronPort-AV: E=Sophos;i="4.75,694,1330923600"; d="scan'208";a="11782108" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 May 2012 16:52:14 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 May 2012 16:51:53 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 31 May 2012 16:54:07 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Cullen Jennings Date: Thu, 31 May 2012 16:54:05 -0400 Thread-Topic: [dispatch] Conference Focus Indicating CCMP Support draft Thread-Index: Ac0/Ne3G5PZGYl4oRYWTKp0UpWkicwAOI6Eg Message-ID: <6369CB70BFD88942B9705AC1E639A338231651A1F2@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A338231294492E@DC-US1MBEX4.global.avaya.com> <30867AE3-83E0-4AB2-BA34-8E4E684D4901@iii.ca> In-Reply-To: <30867AE3-83E0-4AB2-BA34-8E4E684D4901@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Conference Focus Indicating CCMP Support draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 20:54:28 -0000 Thanks Cullen, I appreciate your feedback. I can go either way on the Feature tag vs. Call Info. Do other people have an opinion on this? Thanks, Rifaat > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca] > Sent: Thursday, May 31, 2012 10:02 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Conference Focus Indicating CCMP Support draft >=20 >=20 > I read the draft and I like it - both approach look like they should > work OK. >=20 > The feature tags approach makes sense to me and I seems like the right > way to do this. I could live with the service URI approach. I certainly > don't want both :-) >=20 > Anyways, my 2 cents would be to see what others say and see if you can > get consensus around pursuing the feature tag / Call Info approach. > The extra options message to conf server seems like a drop in the > bucket on the messaging involved with an XCON conference. >=20 > Cullen >=20 >=20 >=20 > On May 26, 2012, at 3:22 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >=20 > > Hi, > > > > Mary and I have submitted the following new draft: > > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- > indication/ > > > > The draft defines a way that enables a client to discover if a > conference focus supports CCMP. > > The draft discusses several options and recommends two of these > options, depending on the need of the client. > > The draft is based on another draft that we submitted to XCON, > https://datatracker.ietf.org/doc/draft-yusef-xcon-ccmp-indication/,but > because XCON is closed we are coming back to DISPATCH. > > > > We are looking to progress this document as an AD sponsored document. > > > > We would appreciate it if people review the document and provide us > with their feedback. > > > > Thanks, > > Rifaat > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch