
From gonzalo.camarillo@ericsson.com  Thu Mar  1 01:09:19 2012
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4421F866B for <rai@ietfa.amsl.com>; Thu,  1 Mar 2012 01:09:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.946
X-Spam-Level: 
X-Spam-Status: No, score=-109.946 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 GlCB44+H7vyR for <rai@ietfa.amsl.com>; Thu,  1 Mar 2012 01:09:18 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2799021F8673 for <rai@ietf.org>; Thu,  1 Mar 2012 01:09:17 -0800 (PST)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-f2-4f4f3cbc5607
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.CE.27041.CBC3F4F4; Thu,  1 Mar 2012 10:09:16 +0100 (CET)
Received: from [131.160.36.168] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Mar 2012 10:09:16 +0100
Message-ID: <4F4F3CBC.2040906@ericsson.com>
Date: Thu, 1 Mar 2012 11:09:16 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <20120221213428.9641.76358.idtracker@ietfa.amsl.com> <4F444A0B.2090908@alum.mit.edu>
In-Reply-To: <4F444A0B.2090908@alum.mit.edu>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rai@ietf.org" <rai@ietf.org>
Subject: Re: [RAI] I-D Action: draft-ietf-sipping-media-policy-dataset-14.txt
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 09:09:19 -0000

Hi Paul,

thanks for your comment. Good catch. Yes, the o/a procedures you refer
to are specified here:

http://tools.ietf.org/html/rfc3264#page-10

I have edited that section so that only codecs that are in both the
offer and the answer are listed. I will be submitting revision 15 of the
draft shortly.

Thanks,

Gonzalo


On 22/02/2012 3:51 AM, Paul Kyzivat wrote:
> (I guess this must go to RAI, since sipping is now closed)
> 
> Somehow I managed to ignore this up till now.
> I have déjà vu reading this - it feels like SDPng has returned. :-)
> 
> I see one possible problem with this:
> 
>> 4.1.  Mapping SDP to Session Info Documents
>>
>>    If a UA has an SDP offer and answer pair [RFC3264] and wants to
>>    create a session info document, the UA uses the answer to fill in the
>>    elements of the session info document except for the <remote-host-
>>    port> and <local-host-port> elements, which are taken from the remote
>>    and local SDP respectively.  (The local SDP is the one sent by the
>>    UA; the remote session description is the one received from the
>>    remote UA.)
> 
> I think this isn't quite right. Specifically, the m-line in the offer 
> can contain those formats from the offer that the answerer wants to use. 
> But it may also contain additional formats that the answerer supports. 
> But those added ones, and the formats in the offer that are not in the 
> answer, cannot be used for the session at that time.
> 
> I think your mapping procedure improperly includes the formats from the 
> answer that weren't in the offer.
> 
> I guess the mapping could simply say to omit those.
> Or you could include <codec> elements for those mentioned in offer or 
> answer but not both with enabled=no and perhaps direction to indicate 
> which side named it.
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai
> 


From richard@shockey.us  Thu Mar  8 15:50:10 2012
Return-Path: <richard@shockey.us>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E371721F86A1 for <rai@ietfa.amsl.com>; Thu,  8 Mar 2012 15:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.711
X-Spam-Level: 
X-Spam-Status: No, score=-98.711 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 QgZXRWAVYQqc for <rai@ietfa.amsl.com>; Thu,  8 Mar 2012 15:50:06 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 98B8021F850C for <rai@ietf.org>; Thu,  8 Mar 2012 15:50:06 -0800 (PST)
Received: (qmail 16428 invoked by uid 0); 8 Mar 2012 23:50:06 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 8 Mar 2012 23:50:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=BdOl7uztS5JgGQ7T2oRoEzML6iNJto4ERlYNutCaue8=;  b=Y0yV6WXHUlONdtkVhSv86cnPKNPv/LelIidV/XJP9SushZDAQA0pwPmyS6md4Q/BunRZzWEl/A2roPufg1AFEMQLR7K9O9iuW7bhoigl7rruMg2m0HoQjYhy5Tyt3dDK;
Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from <richard@shockey.us>) id 1S5n5x-0001Kk-8e; Thu, 08 Mar 2012 16:50:05 -0700
From: "Richard Shockey" <richard@shockey.us>
To: <sipcore@ietf.org>, <dispatch@ietf.org>, <rai@ietf.org>
Date: Thu, 8 Mar 2012 18:50:05 -0500
Message-ID: <001201ccfd86$30d719f0$92854dd0$@us>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CCFD5C.480111F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acz9hi+tXVbYOlEGQ6Svhv7wAz9bcQ==
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us}
Subject: [RAI] SIPNOC news  Dr Henning Schulzrinne will be keynote speaker
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 23:50:11 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01CCFD5C.480111F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

he SIP Forum Announces FCC Chief Technology Officer 

Henning Schulzrinne Keynote Speaker for SIPNOC US 2012

 

SIP Visionary Schulzrinne to address the worldwide service provider
community on SIP technology and opportunities facing the IP communications
industry

 

NORTH ANDOVER, MA (March 5, 2012) - The SIP Forum announced today Federal
Communications Commission (FCC) Chief Technology Officer (CTO) Henning
Schulzrinne as the keynote speaker for the second annual SIP Network
Operators Conference (SIPNOC), being held at the Hyatt Dulles Hotel in
Herndon, VA, June 25-27, 2012. 

 

SIPNOC US 2012 will host an international audience focused on the
operational and technical aspects of Session Initiation Protocol (SIP) in
service provider networks and issues critical to the reliable and successful
deployment and operation of SIP-based services in carrier networks. The
agenda will feature special presentations, panel discussions and workshops
covering key topics by network operators related to SIP-based services and
infrastructure, including testing, application development, SIP trunking,
FoIP, call routing and peering, troubleshooting and monitoring, emergency
services and more. The event website is located at www.sipnoc.org.

"I'm excited to be able to talk about the challenges and opportunities of
moving to an all-IP network to this international audience of network
operational and technical professionals," said Schulzrinne. "As part of my
participation in SIPNOC US 2012, I hope to gain a richer perspective on the
future of SIP-enabled communications among service providers."

 

"The SIP Forum is delighted to have Henning keynote this year's SIPNOC
event," said Richard Shockey, Chairman of the Board of the SIP Forum.
"Henning is universally acclaimed as the Father of the SIP standard. We have
come a long way since the first SIP specification was adopted in 1999, and
we still have much work to do. We look forward to hearing Henning's insights
on where we are headed." 

 

As CTO of the FCC, Schulzrinne guides the organization's work on technology
and engineering issues, together with the FCC's Office of Engineering and
Technology. He advises on matters across the agency to ensure that FCC
policies are driving technological innovation, including serving as a
resource to FCC Commissioners.  Schulzrinne joined the FCC in 2010 as an
Engineering Fellow. 

 

Schulzrinne serves as Julian Clarence Levi Professor of Mathematical Methods
and Computer Science and Professor of Engineering at The Fu Foundation
School of Engineering at Columbia University.  Over the course of his
career, he has published more than 250 journal and conference papers and
more than 70 Internet Requests for Comment (RFCs) - working to shape the key
protocols for enabling voice-over-IP (VoIP) and other multimedia
applications, including the Session Initiation Protocol (SIP) which have
become Internet Standards.  His research interests include Internet
multimedia systems, applied network engineering, wireless networks,
security, quality of service, and performance evaluation.

 

"Mr. Schulzrinne is one of the key architects of the SIP standard, and a
leading mind in the IP communications industry.  We are simply thrilled to
have him take part in this year's SIPNOC event," said Marc Robins, SIP Forum
President and Managing Director. 

 

SIPNOC US 2012 will build on themes first discussed at last year's inaugural
event: addressing issues critical to the reliable and successful deployment
and operation of SIP-based services in carrier networks and the
opportunities that come with it. Among the topics expected to be on the
agenda at this year's conference are SIP trunking interoperability and the
SIP Forum's recently ratified SIPconnect 1.1 technical specification that
provides a definitive and standardized set of guidelines for seamless,
end-to-end interoperability between SIP-enabled IP-PBXs and service provider
networks. Other themes to be discussed include Fax over Internet protocol
(FoIP) interworking, implementing SIP with IPv6, and the sharing of best
practices for the utilization of Wireshark for network diagnostics within IP
network environments. 

 

Attendees at SIPNOC US 2012 will include engineers and network architects
from telecommunications providers, major backbone operators, interconnect
and wholesale solution providers, ISPs, cable operators, wireless network
operators as well as large enterprises deploying major SIP initiatives. At
last year's SIPNOC 2011, informational presentations were made by a number
of professionals from organizations such as Comcast Cable, Cox
Communications, Sprint Nextel, CableLabs and the Internet Engineering Task
Force (IETF). Dr. Douglas C. Sicker, Chief Technologist at the Federal
Communications Commission, provided the keynote speech. 

 

For more information about SIPNOC US 2012, please visit www.sipnoc.org or
send an email to sipnocinfo@sipforum.org. 

 

 

REGISTER TODAY-  $100 Discount for Limited Time 

Registration for SIPNOC US 2012 is now open, and for a limited time
attendees can take advantage of a special $100 discount off the regular
registration rate by entering code "sipnocus12100" on the initial
registration page.  Click here to register or visit
http://www.regonline.com/sipnocus2012.

 

ABOUT THE SIP FORUM

The SIP Forum is an IP communications industry association that engages in
numerous activities that promote and advance SIP-based technology, such as
the development of industry recommendations, the SIPit interoperability and
testing events, special interoperability workshops, educational seminars,
and general promotion of SIP in the industry.  One of the Forum's notable
technical activities is the development of the SIPconnect Technical
Recommendation -- a standards-based recommendation that provides detailed
guidelines for direct IP peering and interoperability between IP PBXs and
VoIP service provider networks. The SIPconnect Compliant Certification
Program is an associated program through which eligible companies can gain
SIPconnect validation and the right to license the use of the SIP Forum's
'SIPconnect Compliant' certification mark -- the official brand of the
leading standard for SIP Trunking products and services. Other important
Forum initiatives include work in Fax-over-IP interoperability, User Agent
Configuration, video interoperability, and SIP and IPv6. For more
information, please visit: http://www.sipforum.org.

 

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
< <mailto:richard(at)shockey.us> mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

 


------=_NextPart_000_0013_01CCFD5C.480111F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>he SIP =
Forum Announces FCC Chief Technology Officer <o:p></o:p></p><p =
class=3DMsoNormal>Henning Schulzrinne Keynote Speaker for SIPNOC US =
2012<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>SIP Visionary Schulzrinne to address the worldwide =
service provider community on SIP technology and opportunities facing =
the IP communications industry<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>NORTH =
ANDOVER, MA (March 5, 2012) - The SIP Forum announced today Federal =
Communications Commission (FCC) Chief Technology Officer (CTO) Henning =
Schulzrinne as the keynote speaker for the second annual SIP Network =
Operators Conference (SIPNOC), being held at the Hyatt Dulles Hotel in =
Herndon, VA, June 25-27, 2012. <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>SIPNOC US =
2012 will host an international audience focused on the operational and =
technical aspects of Session Initiation Protocol (SIP) in service =
provider networks and issues critical to the reliable and successful =
deployment and operation of SIP-based services in carrier networks. The =
agenda will feature special presentations, panel discussions and =
workshops covering key topics by network operators related to SIP-based =
services and infrastructure, including testing, application development, =
SIP trunking, FoIP, call routing and peering, troubleshooting and =
monitoring, emergency services and more. The event website is located at =
www.sipnoc.org.<o:p></o:p></p><p class=3DMsoNormal>&#8220;I&#8217;m =
excited to be able to talk about the challenges and opportunities of =
moving to an all-IP network to this international audience of network =
operational and technical professionals,&#8221; said Schulzrinne. =
&#8220;As part of my participation in SIPNOC US 2012, I hope to gain a =
richer perspective on the future of SIP-enabled communications among =
service providers.&#8221;<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>&#8220;The =
SIP Forum is delighted to have Henning keynote this year&#8217;s SIPNOC =
event,&#8221; said Richard Shockey, Chairman of the Board of the SIP =
Forum. &#8220;Henning is universally acclaimed as the Father of the SIP =
standard. We have come a long way since the first SIP specification was =
adopted in 1999, and we still have much work to do. We look forward to =
hearing Henning&#8217;s insights on where we are headed.&#8221; =
<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>As CTO of the FCC, Schulzrinne guides the =
organization&#8217;s work on technology and engineering issues, together =
with the FCC&#8217;s Office of Engineering and Technology. He advises on =
matters across the agency to ensure that FCC policies are driving =
technological innovation, including serving as a resource to FCC =
Commissioners.&nbsp; Schulzrinne joined the FCC in 2010 as an =
Engineering Fellow. <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Schulzrinne =
serves as Julian Clarence Levi Professor of Mathematical Methods and =
Computer Science and Professor of Engineering at The Fu Foundation =
School of Engineering at Columbia University.&nbsp; Over the course of =
his career, he has published more than 250 journal and conference papers =
and more than 70 Internet Requests for Comment (RFCs) &#8211; working to =
shape the key protocols for enabling voice-over-IP (VoIP) and other =
multimedia applications, including the Session Initiation Protocol (SIP) =
which have become Internet Standards.&nbsp; His research interests =
include Internet multimedia systems, applied network engineering, =
wireless networks, security, quality of service, and performance =
evaluation.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>&#8220;Mr. Schulzrinne is one of the key architects of =
the SIP standard, and a leading mind in the IP communications =
industry.&nbsp; We are simply thrilled to have him take part in this =
year&#8217;s SIPNOC event,&#8221; said Marc Robins, SIP Forum President =
and Managing Director. <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>SIPNOC US =
2012 will build on themes first discussed at last year&#8217;s inaugural =
event: addressing issues critical to the reliable and successful =
deployment and operation of SIP-based services in carrier networks and =
the opportunities that come with it. Among the topics expected to be on =
the agenda at this year&#8217;s conference are SIP trunking =
interoperability and the SIP Forum&#8217;s recently ratified SIPconnect =
1.1 technical specification that provides a definitive and standardized =
set of guidelines for seamless, end-to-end interoperability between =
SIP-enabled IP-PBXs and service provider networks. Other themes to be =
discussed include Fax over Internet protocol (FoIP) interworking, =
implementing SIP with IPv6, and the sharing of best practices for the =
utilization of Wireshark for network diagnostics within IP network =
environments. <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Attendees at =
SIPNOC US 2012 will include engineers and network architects from =
telecommunications providers, major backbone operators, interconnect and =
wholesale solution providers, ISPs, cable operators, wireless network =
operators as well as large enterprises deploying major SIP initiatives. =
At last year&#8217;s SIPNOC 2011, informational presentations were made =
by a number of professionals from organizations such as Comcast Cable, =
Cox Communications, Sprint Nextel, CableLabs and the Internet =
Engineering Task Force (IETF). Dr. Douglas C. Sicker, Chief Technologist =
at the Federal Communications Commission, provided the keynote speech. =
<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>For more information about SIPNOC US 2012, please =
visit www.sipnoc.org or send an email to sipnocinfo@sipforum.org. =
<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>REGISTER =
TODAY&#8211;&nbsp; $100 Discount for Limited Time <o:p></o:p></p><p =
class=3DMsoNormal>Registration for SIPNOC US 2012 is now open, and for a =
limited time attendees can take advantage of a special $100 discount off =
the regular registration rate by entering code =
&#8220;sipnocus12100&#8221; on the initial registration page.&nbsp; =
Click here to register or visit =
http://www.regonline.com/sipnocus2012.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>ABOUT THE =
SIP FORUM<o:p></o:p></p><p class=3DMsoNormal>The SIP Forum is an IP =
communications industry association that engages in numerous activities =
that promote and advance SIP-based technology, such as the development =
of industry recommendations, the SIPit interoperability and testing =
events, special interoperability workshops, educational seminars, and =
general promotion of SIP in the industry.&nbsp; One of the Forum's =
notable technical activities is the development of the SIPconnect =
Technical Recommendation -- a standards-based recommendation that =
provides detailed guidelines for direct IP peering and interoperability =
between IP PBXs and VoIP service provider networks. The SIPconnect =
Compliant Certification Program is an associated program through which =
eligible companies can gain SIPconnect validation and the right to =
license the use of the SIP Forum's 'SIPconnect Compliant' certification =
mark -- the official brand of the leading standard for SIP Trunking =
products and services. Other important Forum initiatives include work in =
Fax-over-IP interoperability, User Agent Configuration, video =
interoperability, and SIP and IPv6. For more information, please visit: =
http://www.sipforum.org.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><span =
style=3D'font-size:10.0pt;font-family:"Times New Roman","serif"'>Richard =
Shockey<br>Shockey Consulting<br>Chairman of the Board of Directors SIP =
Forum<br>PSTN Mobile: +1 703.593.2683<br>&lt;<a =
href=3D"mailto:richard(at)shockey.us"><span =
style=3D'color:blue'>mailto:richard(at)shockey.us</span></a>&gt;<br>skype=
-linkedin-facebook: rshockey101<br>http//www.sipforum.org</span><span =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_000_0013_01CCFD5C.480111F0--


From dean.willis@softarmor.com  Fri Mar  9 10:25:51 2012
Return-Path: <dean.willis@softarmor.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637621F85F2 for <rai@ietfa.amsl.com>; Fri,  9 Mar 2012 10:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.876
X-Spam-Level: 
X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 voVLLiBwLGQ2 for <rai@ietfa.amsl.com>; Fri,  9 Mar 2012 10:25:51 -0800 (PST)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63E0121F85B5 for <rai@ietf.org>; Fri,  9 Mar 2012 10:25:51 -0800 (PST)
Received: by dakl33 with SMTP id l33so1876480dak.31 for <rai@ietf.org>; Fri, 09 Mar 2012 10:25:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5yR3BhCk5tANotqWrq32EiDX2s4L9Fjsi/EeljP2Mwo=; b=dI+noyJhSx1pw9byM0OPOU77s2ItRXzzYr00e1xkv1H67ZTXIjSggQWB/J3eNeS24X ZlD+5AtyLakt0RgIQ2t/hbyQQzF/nM7LRB9UBjpUM7kCXJTZumH70r90E+3WuAumraKG IBRIQwb4cG5tSTn+hUryUzgsK/ClhPZqbwi10=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5yR3BhCk5tANotqWrq32EiDX2s4L9Fjsi/EeljP2Mwo=; b=kIIUbHUKwAkHXbXpOnycACukzAQp2SEmDg51V2fUv80uyHAcJvZTJ5KoXGq3zH/E4r v/QOGLWhLSw5eozAEJjnCjhJ3mUHjk/tivphzrs2mWh8vTuBEBJlRIsgEp6Xyd/vvNpD eI8FhvTEa7qJF9QyLL9z/GVOC1GCy6KE9cXZ86nlgJDOHtlCAcikqrS6Ooe161oIzlFP EjLuIVqahmAyjwGLEsmtR3FDINyvT2tayktNb7XoHxCkBzvRlOdx93HNWE/sztlQFRwU GomnMRwpq+6uTpKr4dJmr6LA6wAQUswNrCGa1x8Qskr4vKZPLQqCxBEOsHjGD+LAPpnP E8BQ==
MIME-Version: 1.0
Received: by 10.68.241.201 with SMTP id wk9mr5749419pbc.136.1331317550302; Fri, 09 Mar 2012 10:25:50 -0800 (PST)
Received: by 10.68.9.104 with HTTP; Fri, 9 Mar 2012 10:25:50 -0800 (PST)
In-Reply-To: <6A523A80-6A5B-4F52-A84A-F2F876555919@nostrum.com>
References: <6A523A80-6A5B-4F52-A84A-F2F876555919@nostrum.com>
Date: Fri, 9 Mar 2012 12:25:50 -0600
Message-ID: <CAOHm=4sxxtPp3G1dxh-9+ibjm1Om7Sq7Jt79sC-y67z67Xe4DQ@mail.gmail.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary=047d7b339939ab45eb04bad385e1
X-Gm-Message-State: ALoCoQlJsdvpTP4nIcLqjEOQLdJlch8elg35lxyTt/sk/gxqI+n7GfVB+jEPyFXYCKLj0P+QYfed
Cc: rai@ietf.org
Subject: Re: [RAI] SIPit 29 Summary
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 18:25:52 -0000

--047d7b339939ab45eb04bad385e1
Content-Type: text/plain; charset=ISO-8859-1

I'm curious about:

"80% of the endpoints present supported SRTP using sdes.
There were no dtls-srtp implementations at this SIPit."


We worked really hard on dtls-srtp for "no implementations". Is this just a
matter of timing, or did dtls-srtp reach too far ahead of the
implementation curve, only to grasp nothingness?


--
Dean

--047d7b339939ab45eb04bad385e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><div><br></div><div>I&#39;m curious about:</div>=
<div>=A0</div></div><span style>&quot;80% of the endpoints present supporte=
d SRTP using sdes.</span><br style><span style>There were no dtls-srtp impl=
ementations at this SIPit.&quot;</span><div>
<span style><br></span></div><div><span style><br></span></div><div><span s=
tyle>We worked really hard on dtls-srtp for &quot;no implementations&quot;.=
 Is this just a matter of timing, or did dtls-srtp reach too far ahead of t=
he implementation curve, only to grasp nothingness?</span></div>
<div><font color=3D"#222222" face=3D"arial, sans-serif"><br></font></div><d=
iv><span style><br></span></div><div><span style>--</span></div><div><span =
style>Dean</span></div>

--047d7b339939ab45eb04bad385e1--

From gonzalo.camarillo@ericsson.com  Sat Mar 17 03:43:34 2012
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE0821F86A6 for <rai@ietfa.amsl.com>; Sat, 17 Mar 2012 03:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.341
X-Spam-Level: 
X-Spam-Status: No, score=-110.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, 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 z80G8QtsM00Q for <rai@ietfa.amsl.com>; Sat, 17 Mar 2012 03:43:27 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C8F0021F85C2 for <rai@ietf.org>; Sat, 17 Mar 2012 03:43:26 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-55-4f646acded95
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 41.63.17856.DCA646F4; Sat, 17 Mar 2012 11:43:25 +0100 (CET)
Received: from [131.160.126.134] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sat, 17 Mar 2012 11:43:25 +0100
Message-ID: <4F646ACC.6030905@ericsson.com>
Date: Sat, 17 Mar 2012 12:43:24 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: rai@ietf.org
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [RAI] Review of 6 new SIP header fields defined by OMA
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2012 10:43:34 -0000

Hi,

OMA has defined 6 new SIP header fields in the following document:

http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf

The relevant sections and Section 5.3 ad Appendix C.

Per RFC 5727, they have requested us to perform an expert review on
these header fields:

http://tools.ietf.org/html/rfc5727#section-4

We will assign an expert to look into this. Nevertheless, any input from
the community on these new header field definitions will be appreciated.

Thanks,

Gonzalo


From pkyzivat@alum.mit.edu  Sat Mar 17 13:30:33 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C0B21F8687 for <rai@ietfa.amsl.com>; Sat, 17 Mar 2012 13:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038,  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 SE3JXl4ErU9B for <rai@ietfa.amsl.com>; Sat, 17 Mar 2012 13:30:32 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABE121F8686 for <rai@ietf.org>; Sat, 17 Mar 2012 13:30:31 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id mkVe1i0030QuhwU58kWX5X; Sat, 17 Mar 2012 20:30:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id mkWX1i00B07duvL3NkWXnN; Sat, 17 Mar 2012 20:30:31 +0000
Message-ID: <4F64F466.90908@alum.mit.edu>
Date: Sat, 17 Mar 2012 16:30:30 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: rai@ietf.org
References: <4F646ACC.6030905@ericsson.com>
In-Reply-To: <4F646ACC.6030905@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [RAI] Review of 6 new SIP header fields defined by OMA
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2012 20:30:33 -0000

I skimmed the referenced document and the header definitions.
I wonder if any consideration was given to reusing existing sip and mime 
headers to accomplish what these new headers are used for. It seems 
there are ones that could be used.

For example:

OMA Header                    Possible Alternative
--------------------------    -------------------------------------
Conversation-ID               Message-ID of 1st message
Contribution-ID               Message-ID
InReplyTo-Contribution-ID     In-Reply-To
Session-Replaces              References(?)
Message-Expires               Expires(?)
Message-UID                   Message-ID

(I don't know much about MIME. But I found defs of some of the above in 
RFC5322. Perhaps someone with detailed knowledge of MIME can 
correct/improve on this.)

Of course I don't fully understand the reasoning behind these new 
headers, and so these mappings may not work. But I think it would be 
worth studying the analogies between sip/oma messaging and email 
messaging/message-threads. We probably need a mime expert to help with that.

(Defining new headers to do the same thing as existing headers 
complicates things for everyone.)

	Thanks,
	Paul

On 3/17/12 6:43 AM, Gonzalo Camarillo wrote:
> Hi,
>
> OMA has defined 6 new SIP header fields in the following document:
>
> http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf
>
> The relevant sections and Section 5.3 ad Appendix C.
>
> Per RFC 5727, they have requested us to perform an expert review on
> these header fields:
>
> http://tools.ietf.org/html/rfc5727#section-4
>
> We will assign an expert to look into this. Nevertheless, any input from
> the community on these new header field definitions will be appreciated.
>
> Thanks,
>
> Gonzalo
>
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai
>


From dworley@avaya.com  Mon Mar 19 14:13:58 2012
Return-Path: <dworley@avaya.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820E621F84FB for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 14:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.918
X-Spam-Level: 
X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=-0.319, 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 g2oiWiZnD-lJ for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 14:13:57 -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 8FC3821F84F1 for <rai@ietf.org>; Mon, 19 Mar 2012 14:13:57 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAK2fZ0/GmAcF/2dsb2JhbABCDrZJgQeCCQEBAQECARIoLRcLAgEIDQEHIRAyJQEBBAEJCQgah2MFmmWcEZACYwSbd4oZgi9T
X-IronPort-AV: E=Sophos;i="4.73,614,1325480400";  d="scan'208";a="234085"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Mar 2012 17:13:56 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Mar 2012 17:05:44 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 19 Mar 2012 17:13:56 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "rai@ietf.org" <rai@ietf.org>
Date: Mon, 19 Mar 2012 17:13:55 -0400
Thread-Topic: [RAI] Review of 6 new SIP header fields defined by OMA
Thread-Index: Ac0EfNFZytH0C6xiQqmu4AnrXBGCOQBlwo9C
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0985@DC-US1MBEX4.global.avaya.com>
References: <4F646ACC.6030905@ericsson.com>,<4F64F466.90908@alum.mit.edu>
In-Reply-To: <4F64F466.90908@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
Subject: Re: [RAI] Review of 6 new SIP header fields defined by OMA
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2012 21:13:58 -0000

> From: Paul Kyzivat [pkyzivat@alum.mit.edu]
>=20
> OMA Header                    Possible Alternative
> --------------------------    -------------------------------------
> Conversation-ID               Message-ID of 1st message
> Contribution-ID               Message-ID
> InReplyTo-Contribution-ID     In-Reply-To
> Session-Replaces              References(?)
> Message-Expires               Expires(?)
> Message-UID                   Message-ID

As far as I can tell, "Message-Id" is copied from RFC 3501 and looks
like it is supposed to carry a "message sequence number within a
conversation", because the BNF is:

    uniqueid        =3D nz-number
			; Strictly ascending

It looks like "Message-Expires" is for when the message being
transferred is large enough to require a dialog.  ("carries the expiry
time associated with the Large Message Mode CPM Standalone Message")
The problem with using "Expires" for this number is that "Expires" is
already used to specify how long the UAS has to respond to the INVITE.
But if the message transfer process takes a while, they seem to want
an additional specification of the point after which transferring the
message can be abandoned.

These headers:

> Conversation-ID               Message-ID of 1st message
> Contribution-ID               Message-ID
> InReplyTo-Contribution-ID     In-Reply-To
> Session-Replaces              References(?)

all have a value that is syntactically "word", as opposed to Call-Id,
whose syntax is "word ['@' word]".  For consistency's sake I'd like to
see them all use the same syntax.  Section 3.2 suggests that the
datatypes of these headers has already been fixed in [OMA-CPM-SD].
But if that is so, why would that document have fixed a syntax which
matches "word" in RFC 3261?

Dale

From adam@nostrum.com  Mon Mar 19 14:27:30 2012
Return-Path: <adam@nostrum.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E7121E8034 for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 14:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 rRA-XmnOVNJ1 for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 14:27:29 -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 E3E9921E801C for <rai@ietf.org>; Mon, 19 Mar 2012 14:27:28 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2JLRP6G020974 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 16:27:27 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F67A4BD.3020502@nostrum.com>
Date: Mon, 19 Mar 2012 16:27:25 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: RAI Area <rai@ietf.org>
Content-Type: multipart/alternative; boundary="------------060900080808070704080909"
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: RAI Area Directors <rai-ads@tools.ietf.org>
Subject: [RAI] Expert Review of 6 new SIP header fields defined by OMA
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2012 21:27:30 -0000

This is a multi-part message in MIME format.
--------------060900080808070704080909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I have been asked by the RAI area directors to review of the SIP header 
fields proposed by the following OMA document:

http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf

I have been designated the formal expert reviewer for this request from 
OMA. Although this is not the formal review (which will be sent in 
response to a request from IANA), the contents of my review will be 
identical to or substantially similar to the following if the current 
proposal is sent to IANA. OMA is encouraged to make adjustments as 
suggested below before proceeding.

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

The OMA proposal "CPM Conversation Functions" describes six new SIP 
header fields. These header fields are intended to facilitate their SIP- 
and MSRP-based instant messaging architecture. I will address each 
proposed header field individually, using the criteria described in 
section 4 RFC 5727.

In particular, I am analyzing for a lack of overlap with existing 
(either complete or in-progress) work in RAI; the absence of significant 
changes in SIP client behavior; and proper treatment of security-related 
issues.

My first comment, which is global, is that this document nearly 
universally uses the term "header" where "header field" is intended. 
While this is largely editorial, RFC3261 does have a clear definition 
for the term "header," and its use in this fashion is nonsensical. This 
does not preclude registration of the header fields.


----------------------------------------
Conversation-ID

Conclusion: Apparently unsuitable for registration (significant client 
behavior change), can be fixed with clearer semantics describing client 
behavior when header field is absent.

This proposed header field does not appear to directly conflict with 
existing or ongoing work in the RAI area. However, its presence is 
likely superfluous, as the SIP Call-ID of the initial message in the 
conversation could trivially be used for this purpose: it has the same 
information properties as the proposed Conversation-ID.

After carefully reviewing both OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C and 
OMA-TS-CPM_System_Description-V1_0-20101012-C, I have serious concerns 
about whether this header field qualifies as "purely informational" and 
as "NOT significantly chang[ing] the behavior of SIP entites that 
support it." In particular, both documents contain normative language 
indicating behavior such as the following:

    "[T]he CPM Participating Function... SHALL extract and locally store
    the following headers of the request: From header; To header; Date
    header, if it exists; Conversation Identity and Contribution
    Identity and if there is, Contribution Identity being replied to."


This text, for example, leaves the behavior undefined when a 
Conversation Identity header field is not present in the SIP message. 
Many implementations will consequently fail to process the request when 
no Conversation-ID header field is sent, which is the most radical 
behavior change possible.

To be acceptable for registration under RFC 5727 guidelines, the 
behavior described in this document (and related documents that discuss 
conversation behavior) need to be revised to clarify that the absence of 
this header field cannot result in substantial changes in client 
behavior, such as failure to process the message.

I will observe that the use of the initial Call-ID of the conversation 
to identify the entire conversation (as suggested above) completely 
eliminates these concerns, as RFC3261 mandates the presence of Call-ID 
in every SIP message.

Since the header field is not presently suitable for registration, I 
will not perform a security analysis for Conversation-ID.

----------------------------------------
Contribution-ID

Conclusion: Apparently unsuitable for registration (significant client 
behavior change), can be fixed with clearer semantics describing client 
behavior when header field is absent.

This proposed header field does not appear to directly conflict with 
existing or ongoing work in the RAI area. However, its presence is 
likely superfluous, as the SIP Call-ID of the message could trivially be 
used for this purpose: it has the same information properties as the 
proposed Contribution-ID.

I have concerns congruent with those for Conversation-ID, in that 
behavior in the absence of the Contribution-ID is not well defined, and 
therefore will likely lead to interoperability failures (which 
constitute significant changes in client behavior). For example:

    "[T]he CPM Participating Function... SHALL, in case of a Pager Mode
    CPM Standalone Message, store the following information: ...
    Contribution-ID; InReplyTo-Contribution-ID (if present)."

This comment may be addressed in the same way as for Conversation-ID.

I will again observe that the use of Call-ID for this function 
eliminates all interoperability concerns.

Since the header field is not presently suitable for registration, I 
will not perform a security analysis for Conversation-ID.

----------------------------------------
InReplyTo-Contribution-ID

Conclusion: Suitable for registration, once security is addressed

This proposed header field does not appear to directly conflict with 
existing or ongoing work in the RAI area, and client behavior in its 
absence appears to be well defined (communications proceed as expected).

Note that the use of Call-ID for identification of contributions would 
allow the use of the already-defined SIP "In-Reply-To." Doing so 
eliminates the need for the definition and registration of a new header 
field.

This header field needs to include a discussion of security: if new 
users are included into an ongoing conversation, the presence of this 
header field can be used to deduce that they did not receive previously 
sent messages on the topic. The very existence of these messages may 
constitute sensitive information that the sender did not intend to 
reveal. In particular, senders should have the ability to suppress this 
header field to avoid leaking such information.

----------------------------------------
Session-Replaces

Conclusion: Unsuitable for registration (overlap with RAI work)

This proposed header field directly conflicts with the "Replaces" header 
field defined by RFC 3891, which constitutes existing work within the 
IETF RAI area. It is not suitable for registration.

I do not believe that the described mechanism can be altered to overcome 
this conflict. OMA should instead employ the mechanism defined by RFC 3891.

----------------------------------------
Message-Expires

Conclusion: Suitable for registration, once security is addressed

This header field avoids overlap with existing RAI work by careful 
scoping its use to the INVITE method. Client behavior in its absence 
appears to be well defined, and does not constitute a significant change 
in SIP client behavior.

This header field needs better discussion of its security properties. In 
particular, implementors need to ensure user expectations around what 
happens when a message expires are properly dealt with. For example: if 
a user sends a message which he expects to expire in one hour, there is 
no guarantee that the recipient will be unable to retrieve the message 
after that time. Further, the recipient device may not preclude the 
storage of received messages well past their expiration.


----------------------------------------
Message-UID

Conclusion: Suitable for registration

This header field does not appear to overlap with any existing RAI work. 
Client behavior in its absence appears to be well defined, and does not 
constitute a significant change in SIP client behavior.

The presence and use of this header field does not appear to introduce 
any security issues.

/a

--------------060900080808070704080909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I have been asked by the RAI area directors to review of the SIP
    header fields proposed by the following OMA document:<br>
    <br>
<a class="moz-txt-link-freetext" href="http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf">http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf</a><br>
    <br>
    I have been designated the formal expert reviewer for this request
    from OMA. Although this is not the formal review (which will be sent
    in response to a request from IANA), the contents of my review will
    be identical to or substantially similar to the following if the
    current proposal is sent to IANA. OMA is encouraged to make
    adjustments as suggested below before proceeding.<br>
    <br>
----------------------------------------------------------------------<br>
    <br>
    The OMA proposal "CPM Conversation Functions" describes six new SIP
    header fields. These header fields are intended to facilitate their
    SIP- and MSRP-based instant messaging architecture. I will address
    each proposed header field individually, using the criteria
    described in section 4 RFC 5727.<br>
    <br>
    In particular, I am analyzing for a lack of overlap with existing
    (either complete or in-progress) work in RAI; the absence of
    significant changes in SIP client behavior; and proper treatment of
    security-related issues.<br>
    <br>
    My first comment, which is global, is that this document nearly
    universally uses the term "header" where "header field" is intended.
    While this is largely editorial, RFC3261 does have a clear
    definition for the term "header," and its use in this fashion is
    nonsensical. This does not preclude registration of the header
    fields.<br>
    <br>
    <br>
    ----------------------------------------<br>
    Conversation-ID<br>
    <br>
    Conclusion: Apparently unsuitable for registration (significant
    client behavior change), can be fixed with clearer semantics
    describing client behavior when header field is absent.<br>
    <br>
    This proposed header field does not appear to directly conflict with
    existing or ongoing work in the RAI area. However, its presence is
    likely superfluous, as the SIP Call-ID of the initial message in the
    conversation could trivially be used for this purpose: it has the
    same information properties as the proposed Conversation-ID.<br>
    <br>
    After carefully reviewing both OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C
    and
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    OMA-TS-CPM_System_Description-V1_0-20101012-C, I have serious
    concerns about whether this header field qualifies as "purely
    informational" and as "NOT significantly chang[ing] the behavior of
    SIP entites that support it." In particular, both documents contain
    normative language indicating behavior such as the following:<br>
    <br>
    <blockquote>"[T]he CPM Participating Function... SHALL extract and
      locally store the following headers of the request: From header;
      To header; Date header, if it exists; Conversation Identity and
      Contribution Identity and if there is, Contribution Identity being
      replied to."<br>
    </blockquote>
    <br>
    This text, for example, leaves the behavior undefined when a
    Conversation Identity header field is not present in the SIP
    message. Many implementations will consequently fail to process the
    request when no Conversation-ID header field is sent, which is the
    most radical behavior change possible.<br>
    <br>
    To be acceptable for registration under RFC 5727 guidelines, the
    behavior described in this document (and related documents that
    discuss conversation behavior) need to be revised to clarify that
    the absence of this header field cannot result in substantial
    changes in client behavior, such as failure to process the message.<br>
    <br>
    I will observe that the use of the initial Call-ID of the
    conversation to identify the entire conversation (as suggested
    above) completely eliminates these concerns, as RFC3261 mandates the
    presence of Call-ID in every SIP message.<br>
    <br>
    Since the header field is not presently suitable for registration, I
    will not perform a security analysis for Conversation-ID.<br>
    <br>
    ----------------------------------------<br>
    Contribution-ID<br>
    <br>
    Conclusion: Apparently unsuitable for registration (significant
    client behavior change), can be fixed with clearer semantics
    describing client behavior when header field is absent.<br>
    <br>
    This proposed header field does not appear to directly conflict with
    existing or ongoing work in the RAI area. However, its presence is
    likely superfluous, as the SIP Call-ID of the message could
    trivially be used for this purpose: it has the same information
    properties as the proposed Contribution-ID.<br>
    <br>
    I have concerns congruent with those for Conversation-ID, in that
    behavior in the absence of the Contribution-ID is not well defined,
    and therefore will likely lead to interoperability failures (which
    constitute significant changes in client behavior). For example:<br>
    <br>
    <blockquote>"[T]he CPM Participating Function... SHALL, in case of a
      Pager Mode CPM Standalone Message, store the following
      information: ... Contribution-ID; InReplyTo-Contribution-ID (if
      present)."<br>
    </blockquote>
    This comment may be addressed in the same way as for
    Conversation-ID.<br>
    <br>
    I will again observe that the use of Call-ID for this function
    eliminates all interoperability concerns.<br>
    <br>
    Since the header field is not presently suitable for registration, I
    will not perform a security analysis for Conversation-ID.<br>
    <br>
    ----------------------------------------<br>
    InReplyTo-Contribution-ID<br>
    <br>
    Conclusion: Suitable for registration, once security is addressed<br>
    <br>
    This proposed header field does not appear to directly conflict with
    existing or ongoing work in the RAI area, and client behavior in its
    absence appears to be well defined (communications proceed as
    expected).<br>
    <br>
    Note that the use of Call-ID for identification of contributions
    would allow the use of the already-defined SIP "In-Reply-To." Doing
    so eliminates the need for the definition and registration of a new
    header field.<br>
    <br>
    This header field needs to include a discussion of security: if new
    users are included into an ongoing conversation, the presence of
    this header field can be used to deduce that they did not receive
    previously sent messages on the topic. The very existence of these
    messages may constitute sensitive information that the sender did
    not intend to reveal. In particular, senders should have the ability
    to suppress this header field to avoid leaking such information.<br>
    <br>
    ----------------------------------------<br>
    Session-Replaces<br>
    <br>
    Conclusion: Unsuitable for registration (overlap with RAI work)<br>
    <br>
    This proposed header field directly conflicts with the "Replaces"
    header field defined by RFC 3891, which constitutes existing work
    within the IETF RAI area. It is not suitable for registration.<br>
    <br>
    I do not believe that the described mechanism can be altered to
    overcome this conflict. OMA should instead employ the mechanism
    defined by RFC 3891.<br>
    <br>
    ----------------------------------------<br>
    Message-Expires<br>
    <br>
    Conclusion: Suitable for registration, once security is addressed<br>
    <br>
    This header field avoids overlap with existing RAI work by careful
    scoping its use to the INVITE method. Client behavior in its absence
    appears to be well defined, and does not constitute a significant
    change in SIP client behavior.<br>
    <br>
    This header field needs better discussion of its security
    properties. In particular, implementors need to ensure user
    expectations around what happens when a message expires are properly
    dealt with. For example: if a user sends a message which he expects
    to expire in one hour, there is no guarantee that the recipient will
    be unable to retrieve the message after that time. Further, the
    recipient device may not preclude the storage of received messages
    well past their expiration.<br>
    <br>
    <br>
    ----------------------------------------<br>
    Message-UID<br>
    <br>
    Conclusion: Suitable for registration<br>
    <br>
    This header field does not appear to overlap with any existing RAI
    work. Client behavior in its absence appears to be well defined, and
    does not constitute a significant change in SIP client behavior.<br>
    <br>
    The presence and use of this header field does not appear to
    introduce any security issues.<br>
    <br>
    /a<br>
  </body>
</html>

--------------060900080808070704080909--

From nancy.greene@ericsson.com  Mon Mar 19 18:09:21 2012
Return-Path: <nancy.greene@ericsson.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1413A21F8760 for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 18:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wRPrKFdnKird for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 18:09:20 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2337C21F87E1 for <rai@ietf.org>; Mon, 19 Mar 2012 18:09:20 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2K19Dn6016668; Mon, 19 Mar 2012 20:09:16 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.46]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 19 Mar 2012 21:09:12 -0400
From: Nancy Greene <nancy.greene@ericsson.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "rai@ietf.org" <rai@ietf.org>
Date: Mon, 19 Mar 2012 21:09:11 -0400
Thread-Topic: [RAI] Review of 6 new SIP header fields defined by OMA
Thread-Index: Ac0EfNFZytH0C6xiQqmu4AnrXBGCOQBlwo9CAAh8x0A=
Message-ID: <AEA158B0C52AEC4394D7B68A331367F46C8BF92CFE@EUSAACMS0703.eamcs.ericsson.se>
References: <4F646ACC.6030905@ericsson.com>,<4F64F466.90908@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A0985@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0985@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [RAI] Review of 6 new SIP header fields defined by OMA
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2012 01:09:21 -0000

=20
Hi, some answers below to Dale's email:

...

>It looks like "Message-Expires" is for when the message being transferred =
is large enough to require a dialog. =20
>("carries the expiry >time associated with the Large Message Mode CPM Stan=
dalone Message") The problem with using=20
>"Expires" for this number is that "Expires" is already used to specify how=
 long the UAS has to respond to the INVITE.

[Nancy] correct

>But if the message transfer process takes a while, they seem to want an ad=
ditional specification of the point after which
>transferring the message can be abandoned.

[Nancy] Actually it is not that the message transfer process may take a whi=
le, it is that this message might be deferred and stored in the network if =
the recipient is not available, so message-expires is a way for the sender =
to indicate the expiry time of the message.=20

>These headers:

>> Conversation-ID               Message-ID of 1st message
>> Contribution-ID               Message-ID
>> InReplyTo-Contribution-ID     In-Reply-To
>> Session-Replaces              References(?)

>all have a value that is syntactically "word", as opposed to Call-Id, whos=
e syntax is "word ['@' word]".  For consistency's sake I'd=20
>like to see them all use the same syntax.  Section 3.2 suggests that the d=
atatypes of these headers has already been fixed in=20
>[OMA-CPM-SD].

[Nancy] Call-Id syntax was not considered since the values of these headers=
 should be created in a way unrelated to Call-Id.  These ID's are expected =
to simply be copied over at B2BUA's so they will remain the same on an end =
to end basis.

>Dale

Nancy


From nancy.greene@ericsson.com  Mon Mar 19 18:20:20 2012
Return-Path: <nancy.greene@ericsson.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267BD21F883E for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 18:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 r6gIes7TE1Ni for <rai@ietfa.amsl.com>; Mon, 19 Mar 2012 18:20:15 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 664F721F87D3 for <rai@ietf.org>; Mon, 19 Mar 2012 18:20:15 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2K1KCqk017184; Mon, 19 Mar 2012 20:20:14 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.46]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 19 Mar 2012 21:20:07 -0400
From: Nancy Greene <nancy.greene@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "rai@ietf.org" <rai@ietf.org>
Date: Mon, 19 Mar 2012 21:20:05 -0400
Thread-Topic: [RAI] Review of 6 new SIP header fields defined by OMA
Thread-Index: Ac0EfNFZytH0C6xiQqmu4AnrXBGCOQBlwo9CAAiOUvA=
Message-ID: <AEA158B0C52AEC4394D7B68A331367F46C8BF92D03@EUSAACMS0703.eamcs.ericsson.se>
References: <4F646ACC.6030905@ericsson.com>,<4F64F466.90908@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A0985@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0985@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [RAI] Review of 6 new SIP header fields defined by OMA
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2012 01:20:20 -0000

Hi, here is some more information on these headers and why the suggested al=
ternatives were not used:
=20
> From: Paul Kyzivat [pkyzivat@alum.mit.edu]
...
> OMA Header                    Possible Alternative
> --------------------------    -------------------------------------
> Conversation-ID               Message-ID of 1st message
There was a requirement in the OMA CPM work for more than just messages to =
be grouped together. It was meant to also cover file transfers and chat ses=
sions, for example. So any standalone message, chat session or file transfe=
r that was all related to the same "conversation" would have the same conve=
rsation-id.

> Contribution-ID               Message-ID
Again, it has to apply to more than messages - it has to apply to chat sess=
ions and file transfers too.

> InReplyTo-Contribution-ID     In-Reply-To
A header with the equivalent syntax to the Contribution-ID was created.

> Session-Replaces              References(?)
This is supposed to carry a Contribution-ID - not sure where References is =
defined.

> Message-Expires               Expires(?)
Since it is used for sending a large message using INVITE and MSRP, Expires=
 could not be used since it has another meaning in a SIP INVITE.

> Message-UID                   Message-ID
This header is related to the way messages are identified in a message stor=
e.

Nancy

_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

From dworley@avaya.com  Tue Mar 20 07:54:57 2012
Return-Path: <dworley@avaya.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2B21F8522 for <rai@ietfa.amsl.com>; Tue, 20 Mar 2012 07:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.412
X-Spam-Level: 
X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, 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 7ZAX4AXr7tBU for <rai@ietfa.amsl.com>; Tue, 20 Mar 2012 07:54:57 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF8A21F850D for <rai@ietf.org>; Tue, 20 Mar 2012 07:54:57 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EANOZaE/GmAcF/2dsb2JhbABCDrZEgQeCCQEBAQECARIoRAsCAQgNCCEQMiUBAQQBEggah2MFmx+cLJAbYwSbbooYgjBT
X-IronPort-AV: E=Sophos;i="4.73,618,1325480400"; d="scan'208";a="337928259"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Mar 2012 10:54:54 -0400
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Mar 2012 10:46:38 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 20 Mar 2012 10:54:52 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Nancy Greene <nancy.greene@ericsson.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "rai@ietf.org" <rai@ietf.org>
Date: Tue, 20 Mar 2012 10:50:53 -0400
Thread-Topic: [RAI] Review of 6 new SIP header fields defined by OMA
Thread-Index: Ac0EfNFZytH0C6xiQqmu4AnrXBGCOQBlwo9CAAh8x0AAHMKhAw==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0988@DC-US1MBEX4.global.avaya.com>
References: <4F646ACC.6030905@ericsson.com>,<4F64F466.90908@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A0985@DC-US1MBEX4.global.avaya.com>, <AEA158B0C52AEC4394D7B68A331367F46C8BF92CFE@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <AEA158B0C52AEC4394D7B68A331367F46C8BF92CFE@EUSAACMS0703.eamcs.ericsson.se>
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: [RAI] Review of 6 new SIP header fields defined by OMA
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2012 14:54:58 -0000

> From: Nancy Greene [nancy.greene@ericsson.com]
>=20
> >> Conversation-ID               Message-ID of 1st message
> >> Contribution-ID               Message-ID
> >> InReplyTo-Contribution-ID     In-Reply-To
> >> Session-Replaces              References(?)
>=20
> >all have a value that is syntactically "word", as opposed to Call-Id,
> >whose syntax is "word ['@' word]".  For consistency's sake I'd like
> >to see them all use the same syntax.  Section 3.2 suggests that the
> >datatypes of these headers has already been fixed in [OMA-CPM-SD].
>=20
> [Nancy] Call-Id syntax was not considered since the values of these
> headers should be created in a way unrelated to Call-Id.  These ID's
> are expected to simply be copied over at B2BUA's so they will remain
> the same on an end to end basis.

Yes, these field values are never copied to/from a Call-Id field
value.  For some reason, the syntax for the values of these fields was
chosen to be 'word' from RFD 3261.  The header field in SIP whose
value has the most-semantically-similar datatype is Call-Id.  To
minimize complexity, that would suggest that these fields should use
the same value syntax as Call-Id, viz., 'word ["@" word]'.  But there
may be other considerations that I am not aware of.

Dale
