From nobody Wed Aug 2 16:23:49 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F591321A7; Wed, 2 Aug 2017 16:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vebULhvg767Y; Wed, 2 Aug 2017 16:23:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD1F1294A2; Wed, 2 Aug 2017 16:23:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BEC19B8124A; Wed, 2 Aug 2017 16:23:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sipcore@ietf.org Message-Id: <20170802232334.BEC19B8124A@rfc-editor.org> Date: Wed, 2 Aug 2017 16:23:34 -0700 (PDT) Archived-At: Subject: [sipcore] RFC 8217 on Clarifications for When to Use the name-addr Production in SIP Messages X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:23:42 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8217 Title: Clarifications for When to Use the name-addr Production in SIP Messages Author: R. Sparks Status: Standards Track Stream: IETF Date: August 2017 Mailbox: rjsparks@nostrum.com Pages: 6 Characters: 12829 Updates: RFC 3261, RFC 3325, RFC 3515, RFC 3892, RFC 4508, RFC 5002, RFC 5318, RFC 5360, RFC 5502 I-D Tag: draft-ietf-sipcore-name-addr-guidance-02.txt URL: https://www.rfc-editor.org/info/rfc8217 DOI: 10.17487/RFC8217 RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative. This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502). This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Aug 10 13:28:47 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02963132356; Thu, 10 Aug 2017 13:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4syLYpQ_pkII; Thu, 10 Aug 2017 13:28:42 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5701D128A32; Thu, 10 Aug 2017 13:28:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d136so10732435qkg.3; Thu, 10 Aug 2017 13:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iEvqkGJQmQO0Ju5AZ2ID60rcGbGMXBB566PowjCPYlY=; b=lhNK8b9bVhtiS68zYfyUu+byEwUobXUG3Gf1uW2TnU1lybwF2TkttSpF/Bg0ZQM4lG yUir9s+9l7m3Perb5XaiG5mKD9r6wz4LHke4EhZJp78GZHu+lqpGEPaYRvA4zPLzyHqq Sv9xqFXqLRaqPh/SFdIIbNFJp/ftB6QCX9HbF5f7vhlL6+NuyZ0kDPMnONkwDS+PXu5Q 87nJAXqPEzQoYuWxjD0BEpy4nVQa72+84e95F7AY3c2wWw6ObwFMEVTllEwf5Fe9hWqW 1NNUxO9/nH+x64LOPG86z9X/zz38CoDqHYJtWeac6+il0ifqUXcmmr9OJ8npRTUiJtVr cNRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iEvqkGJQmQO0Ju5AZ2ID60rcGbGMXBB566PowjCPYlY=; b=eviGGxiV9EqtyPWxVtOyn0st+Y0OYpY6HAPAjjT1VKz0hTqa2e3XqpROWnBsVckdEL WIiCTqt7W5u0GVjK2QPkmJU3AOvkg9bTS55OsL9KYEMq/A9scf7QpymrWdSdqtGNR+1h iC/vBuqP7f3yRCPr6Z65w2hsVky0ckI6q4SIbih/KAkvvLCviQyvBwdMt0t/yjlB9gVR 9f8qHGADIp/H3zW2P8hfETbgktBBsmatNW2/v9a1Gv7TDNc8nc7OcPMUNa2M1bw3zCzr 89ug1wPpybE70yKFqdjt1xAl8f9cEMhWWDtcntXQ2VM/ejPbtuyn2oC3+tJMrzl3/J+B Nexw== X-Gm-Message-State: AHYfb5iOlsQFHRFT7OL20eoeHXnN9OGtH1ShlKTk3f0TDzeTO5eKHJrV 4CCo0+986SdtxrXAr66O1Q8ZUm9MudG+ X-Received: by 10.55.15.164 with SMTP id 36mr16126543qkp.242.1502396920920; Thu, 10 Aug 2017 13:28:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.10 with HTTP; Thu, 10 Aug 2017 13:28:39 -0700 (PDT) In-Reply-To: References: <598a1d5e.0157810a.baf63.13acSMTPIN_ADDED_BROKEN@mx.google.com> From: Mary Barnes Date: Thu, 10 Aug 2017 15:28:39 -0500 Message-ID: To: SIPCORE , DISPATCH Content-Type: multipart/alternative; boundary="001a11474d86c87d4b05566c0a7e" Archived-At: Subject: [sipcore] Fwd: [SIPForum-fullmembers] The SIP Forum Opens Call for Presentations and Early-Bird Registration for SIPNOC 2017 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:28:46 -0000 --001a11474d86c87d4b05566c0a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Apologies to those who might have already seen this on SIP Forum mailing lists, but I think this conference is directly relevant to folks doing work in SIP. This will be the 6th year for the conference. The conference has been well attended by service providers in the past. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Tue, Aug 8, 2017 at 3:21 PM Subject: [SIPForum-fullmembers] The SIP Forum Opens Call for Presentations and Early-Bird Registration for SIPNOC 2017 To: fullmembers@sipforum.org *The SIP Forum Opens Call for Presentations and Early-Bird Registration for SIPNOC 2017, November 28 =E2=80=93 30, 2017**Proposals now accepted for wor= kshops, panels, speaker presentations and "Birds of a Feather" sessions addressing the deployment of SIP in service provider environments; Wireshark Training Workshop included; Registration officially opens* The SIP Forum announced today that it has opened registration and the official Call for Presentations for the seventh annual SIP Network Operators Conference (SIPNOC 2017), being held at the Hilton Washington Dulles Hotel in Herndon, VA, November 28 -30, 2017. A three-day educational conference focusing on the challenges and opportunities related to the deployment of SIP-based carrier services globally, SIPNOC 2017 is a unique, network operator-centric event. Organizers invite companies, executives and industry insiders to propose presentations highlighting the use of session initiation protocol (SIP) in service provider environments. Operators are encouraged to present SIP-related success stories, deployment issues and concerns in their networks, while equipment vendors and other industry stakeholders are invited to work with operators to present real-world deployment experiences= . The* SIPNOC *conferences attractleading technical and operations personnel from the global carrier community and have earned high praise from attendees for their educational, non-commercial and technical content that focuses on the real-world challenges operators face when deploying SIP services in global IP networks. *SIPNOC 2017 *attendees will include 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. The SIP Forum will once again offer specialized training at SIPNOC 2017 presented by the expert trainers of ECG, this year focused on learning the numerous tips and tricks of Wireshark =E2=80=93 *available to all SIPNOC 20= 17 =E2=80=9CAll-Access=E2=80=9D and =E2=80=9CFull Member=E2=80=9D attendees at= no additional cost! * This intensive =E2=80=9CWireshark for VoIP Ninjas=E2=80=9D workshop will eq= uip you with the core and advanced skills you need to diagnose and solve the thorniest problems using the popular, open-source tool Wireshark. The course prepares to you to install and configure Wireshark to maximize your effectiveness for VoIP, creating captures, locating calls and associated media, analyzing QoS for audio and video problems, and using Wireshark=E2=80=99s analytics t= ools to find trouble spots in a busy SIP/IMS VoIP network. *Early-Bird Registration for attending SIPNOC 2017 is now open, and participants registering before September 15, 2017 save $200. Click here to register or visit https://www.regonline.com/sipnoc2017 .* *SIPNOC 2017 Call for Presentations *proposals can be submitted by visiting the SIP Forum Call for Presentations webpage . Possible topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. *SIPNOC 2017* offers several different types of speaking opportunities including: - *General Session Talks*: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - *General Session Panels*: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - *Special Workshops*: The *SIPNOC 2017* program has been expanded to include special workshops that run for 1-2 hours, providing time to focu= s in-depth on a variety of issues important to the SIPNOC community. Topic= s can include a review of SIP RFCs and standards development, the regulato= ry environment, etc. - *Research Topics*: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, network performance, statistical measurement and analysis and protocol development and implementation. Studies presented may be works in progre= ss. Researchers from academia, government, and industry are encouraged to present. - *BOFs*: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. *SIPNOC 2017 Call for Presentation Key Dates* - Presentation Abstracts Due September 1, 2017 - Draft Presentations Due September 14, 2017 - Acceptance Decision and Notifications September 20, 2017 - Draft Program Published September 20, 2017 - Final Presentations Due October 20, 2017 - Final Agenda Published October 23, 2017 - Conference Begins November 28, 2017 *SIPNOC 2017 Call for Presentations General Info* To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit https://www.sipforum.org/news- events/sipnoc-2017-overview/sipnoc-2017-call-for-presentations/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2017. *SIPNOC 2017 Early Bird Registration Info: Deadline September 15, 2017* - *Save $200 *if you register for SIPNOC 2017 by September 15, 2017. - *Register *at https://www.regonline.com/sipnoc2017 *SIPNOC 2017 General Event Information* - For more information about *SIPNOC 2017*, please visit www.sipnoc.org or send an email to sipnocinfo@sipforum.org. *SIPNOC 2017 Sponsorship Information* - For information about corporate sponsorship opportunities at *SIPNOC 2017*, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 <(203)%20829-6307> or marc.robins =E2=80=9Cat= =E2=80=9D sipforum.org. *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 testing events, special workshops, educational seminars, and general promotion of SIP in the industry. The SIP Forum is also the producer of the annual SIPNOC conferences (for SIP Network Operators Conference), focused on the technical requirements of the service provider community. One of the Forum's notable technical activities is the development of the SIPconnect Technical Recommendation =E2=80=93 a standards-based SIP trunking recommend= ation for direct IP peering and interoperability between IP PBXs and SIP-based service provider networks, and the SIPconnect Certification Testing Program, a unique certification testing program that includes a new certification test suite and test platform, as well as an associated =E2=80=9CSIPconnect Certified=E2=80=9D logo program that provides an offici= al =E2=80=9Cseal of certification=E2=80=9D for companies products and services that have succes= sfully passed the certification test and officially achieved conformance with the SIPconnect specification. Other important Forum initiatives include work in NNI, VRS, and SIP and IPv6. For more information, please visit: https://www.sipforum.org. For more information, please visit: *www.sipnoc.org or email sipnocinfo@sipforum.org * _______________________________________________ fullmembers mailing list fullmembers@sipforum.org http://mail.sipforum.org/mailman/listinfo/fullmembers --001a11474d86c87d4b05566c0a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Apologies to those who might ha= ve already seen this on SIP Forum mailing lists, but I think this conferenc= e is directly relevant to folks doing work in SIP.=C2=A0 This will be the 6= th year for the conference. =C2=A0=C2=A0Th= e conference has been well attended by service providers in the past.

Regards,
Mary.



=
---------- Forwarded message ----------
From:= Marc Robins <marc.robins@sipforu= m.org>
Date: Tue, Aug 8, 2017 at 3:21 PM
Subject: [SIPF= orum-fullmembers] The SIP Forum Opens Call for Presentations and Early-Bird= Registration for SIPNOC 2017
To: fullmembers@sipforum.org


= =C2=A0

=C2=A0

=C2=A0<= u>

The SIP Forum Opens Call for Presentations and= Early-Bird Registration for SIPNOC 2017, November 28 =E2=80=93 30, 2017<= h1 style=3D"margin-bottom:14.5pt;line-height:18pt">Pro= posals now accepted for workshops, panels, speaker presentations and "= Birds of a Feather" sessions addressing the deployment of SIP in servi= ce provider environments; Wireshark Training Workshop included; Registratio= n officially opens

The SIP Forum<= /a> announced today that it has opened registration and the official Call for Presentations for t= he seventh annual SIP = Network Operators Conference (SIPNOC 2017), being held at the Hilton Wa= shington Dulles Hotel in Herndon, VA, November 28 -30, 2017.

A thre= e-day educational conference focusing on the challenges and opportunities r= elated to the deployment of SIP-based carrier services globally, SIPNOC 201= 7 is a unique, network operator-centric event. Organizers invite companies,= executives and industry insiders to propose presentations highlighting the= use of session initiation protocol (SIP) in service provider environments.= Operators are encouraged to present SIP-related success stories, deploymen= t issues and concerns in their networks, while equipment vendors and other = industry stakeholders are invited to work with operators to present real-wo= rld deployment experiences.

The SIPNOC conferences attractleading techni= cal and operations personnel from the global carrier community and have ear= ned high praise from attendees for their educational, non-commercial and te= chnical content that focuses on the real-world challenges operators face wh= en deploying SIP services in global IP networks. SIPNOC 2017 attendees will inc= lude telecommunications providers, major backbone operators, interconnect a= nd wholesale solution providers, ISPs, cable operators, wireless network op= erators as well as large enterprises deploying major SIP initiatives.
The SIP Forum will once again offer specialized training at SIPNOC 2017 p= resented by the expert trainers of ECG, this year focused on learning the n= umerous tips and tricks of Wireshark =E2=80=93 available to all SIPNOC 2017 =E2=80=9CAll-Access= =E2=80=9D and =E2=80=9CFull Member=E2=80=9D attendees at no additional cost= !

This intensive =E2=80=9CWireshark for VoIP Ninjas= =E2=80=9D workshop will equip you with the core and advanced skills you nee= d to diagnose and solve the thorniest problems using the popular, open-sour= ce tool Wireshark. The course prepares to you to install and configure Wire= shark to maximize your effectiveness for VoIP, creating captures, locating = calls and associated media, analyzing QoS for audio and video problems, and= using Wireshark=E2=80=99s analytics tools to find trouble spots in a busy = SIP/IMS VoIP network.

Early-Bird Registration for attending SIPNOC 2017 is= now open, and participants registering before September 15, 2017 save $200= . Click = here to register or visit https://www.regonline.com/sipnoc2017.=

SIP= NOC 2017 Call for Presentations proposals can be submitted = by visiting the SIP Forum = Call for Presentations webpage. Possible topics can include SIP peering= , SIP trunking, Emergency Services, Congestion Control, Scaling and Capacit= y Issues, SIP-based applications, Routing, Security, SIP-Network Operations= Center Best Practices, IPv6 deployment challenges, User-agent Configuratio= n, Standardization Issues and Progress, HD voice deployments, Video Interop= erability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues fa= cing SIP network operations.

SIPNOC 2017 offers several different types= of speaking opportunities including:

    <= li class=3D"MsoNormal" style=3D"line-height:17.25pt">General Session Talks: A General Session presentation = should be on a topic of interest to the general SIPNOC audience, and may be= up to 30 minutes long (including time for Q&A). <= /li>
  • General Sessio= n Panels: Pa= nels are sessions with a moderator and a team of panelists. The panel moder= ator should submit an abstract on the panel topic, a list of panelists, and= how the panel will be organized. Panel selection is based on the importanc= e, originality, focus and timeliness of the topic, expertise of proposed pa= nelists, as well as the potential for informative and controversial discuss= ion.
  • Special Workshops: The SIPNOC 2017 program has been expanded to include specia= l workshops that run for 1-2 hours, providing time to focus in-depth on a v= ariety of issues important to the SIPNOC community. Topics can include a re= view of SIP RFCs and standards development, the regulatory environment, etc= .
  • Research Topics: Researchers are invited to present short summaries of their = work for operator feedback. Topics may include call routing, network perfor= mance, statistical measurement and analysis and protocol development and im= plementation. Studies presented may be works in progress. Researchers from = academia, government, and industry are encouraged to present.=
  • BOFs: BOFs (Birds = of a Feather sessions) are informal sessions on topics which are of interes= t to a portion of the SIPNOC community. BOFs may be held in break=E2=80=90o= ut areas or in an unscheduled room. Requests for scheduled BOFs can be made= at any time, including on site at the conference.

= =C2=A0

<= /tr>

SIP= NOC 2017 Call for Presentation Key Dates =

=C2=A0

=C2=A0

  • Presentation Abstracts D= ue

September 1, 2017

  • Draft Presentations Due <= u>

September 14, 2017

  • Acceptance Decision and No= tifications

September 20, 2017 <= /u>

  • Draft Program P= ublished

September 20, 2017 =

  • Final Presentation= s Due

October 20, 2017

<= /td>
  • Final Agenda Published =

October 23, 2017

  • = Conference Begins<= /u>

November 28, 2017

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

SIPNOC 2= 017 Call for Presentations General Info To view the officia= l call for presentations, which includes instructions on submitting materia= l and specific SIPNOC policies, please visit https://www.sipforum.org/news-events/sipnoc-2017-ov= erview/sipnoc-2017-call-for-presentations/. To submit, visit = https://www.easychair.org/conferences/?conf=3Dsipnoc2017.

SIPNOC 2017 Early Bird Registration Info: Deadline Septem= ber 15, 2017

SIPNOC 2017 General Even= t Information

SIPNOC 2017 Sponsorship = Information

  • For information about corporate sponsorship opportunities at = SIPNOC 2017, please contact Marc Robins, SIP Forum President and Managing Direc= tor, at 203-829-6307 or marc.robins =E2=80=9Cat=E2=80=9D sipforum.org.

=C2=A0


About the SIP= Forum

The SIP Forum is an IP communications industry association t= hat engages in numerous activities that promote and advance SIP-based techn= ology, such as the development of industry recommendations, the SIPit inter= operability testing events, special workshops, educational seminars, and ge= neral promotion of SIP in the industry. The SIP Forum is also the producer = of the annual SIPNOC conferences (for SIP Network Operators Conference), fo= cused on the technical requirements of the service provider community. One = of the Forum's notable technical activities is the development of the S= IPconnect Technical Recommendation =E2=80=93 a standards-based SIP trunking= recommendation for direct IP peering and interoperability between IP PBXs = and SIP-based service provider networks, and the SIPconnect Certification T= esting Program, a unique certification testing program that includes a new = certification test suite and test platform, as well as an associated =E2=80= =9CSIPconnect Certified=E2=80=9D logo program that provides an official =E2= =80=9Cseal of certification=E2=80=9D for companies products and services th= at have successfully passed the certification test and officially achieved = conformance with the SIPconnect specification. Other important Forum initia= tives include work in NNI, VRS, and SIP and IPv6. For more information, ple= ase visit: https://= www.sipforum.org.


For more information, please visit:
www.sipnoc.org or email sipnocinfo@sipforum.o= rg

<= /td>


_____________= __________________________________
fullmembers mailing list
fullmembers@s= ipforum.org
http://mail.sipforum.org/mailman/listinfo/= fullmembers



--001a11474d86c87d4b05566c0a7e-- From nobody Tue Aug 29 01:58:44 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EED132D5F for ; Tue, 29 Aug 2017 01:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f71DwXwKuX-1 for ; Tue, 29 Aug 2017 01:58:41 -0700 (PDT) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CAE1329C0 for ; Tue, 29 Aug 2017 01:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1503997120; x=1535533120; h=from:to:subject:date:message-id:mime-version; bh=7RbUtQSpIt1tLdsx/LkiwHVhekD3zFcvSdskysN7bhw=; b=aVVgGfhaoBuiu59LjvkxsqySLawG0067ZZXmniHQA9s0YlyzxCElzBZu EqVFoLYaPL1IhPpagC4qKPifnvsL/18GlcoB4CfjmCPR9TNeu7zEgLgyu 4d7uATDFArcwRRQCfl1u5/c1fDIRTjusUqzR6zlEv20eXl5mg4veDTZ24 SmAqFFb8hF5hku+dnqxxhI5MqzQhwS/8Z7aMFgD/GKBBpQz6YapQc5WSX nM/3o0UxW0Hbj7eJZjs94pj1VQyY+9VByiJcw5FzAqdmydH3KUMAi4XX+ C4jI6HQef15LJNrBnKRmLv/ooF8zhu80+ndleMZ/usRk+CLdPlJWcJ7up w==; Received: from q4de8ssaz61.gppng.telekom.de ([10.206.166.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 10:58:37 +0200 X-IronPort-AV: E=Sophos;i="5.41,444,1498514400"; d="scan'208,217";a="1240712365" Received: from he105831.emea1.cds.t-internal.com ([10.169.119.34]) by q4de8ssazdv.gppng.telekom.de with ESMTP/TLS/AES256-SHA; 29 Aug 2017 10:58:36 +0200 Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105831.emea1.cds.t-internal.com (10.169.119.34) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 29 Aug 2017 10:58:36 +0200 Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1293.002; Tue, 29 Aug 2017 10:58:36 +0200 From: To: Thread-Topic: draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNg== Date: Tue, 29 Aug 2017 08:58:36 +0000 Message-ID: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.168.56] Content-Type: multipart/alternative; boundary="_000_87cf2edcef014e268e000ef358cc3c2cHE105828emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 08:58:43 -0000 --_000_87cf2edcef014e268e000ef358cc3c2cHE105828emea1cdstintern_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, since I have uploaded the latest draft on draft-winterbottom-sipcore-locpar= am-01.txt and the last clarification on questions were given on 23. May I d= id not get any further comment. With a reference to this draft a Liaison from ETSI ( https://datatracker.ie= tf.org/liaison/1527/ ) is waiting for action. The liaison from ETSI is asking on the progress of the draft for their solu= tion on Emergency Call due to the Project of the European Union Mandate: M= 493. My question is, since we have no open questions, if we can now progress the= draft. Thank you for consideration. Best Regards Roland --_000_87cf2edcef014e268e000ef358cc3c2cHE105828emea1cdstintern_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

since I have uploaded the lates= t draft on draft-winterbottom-sipcore-locparam-01.txt and the last clarific= ation on questions were given on 23. May I did not get any further comment.= 

 

With a reference to this dr=
aft a Liaison from ETSI ( h=
ttps://datatracker.ietf.org/liaison/1527/ =
) is waiting for action.


 

The liaison from ETSI is as=
king on the progress of the draft for their solution on Emergency Call due =
to the Project of  the European Union Mandate: M493.=



My question is, since we ha=
ve no open questions, if we can now progress the draft. <=
/pre>

 

Thank you for consideration=
.


 

Best Regards


 

Roland 

 

 

 

 

 

 

 
--_000_87cf2edcef014e268e000ef358cc3c2cHE105828emea1cdstintern_-- From nobody Thu Aug 31 04:29:58 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C996132D5A; Thu, 31 Aug 2017 04:29:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150417899162.16928.8806134655992890779@ietfa.amsl.com> Date: Thu, 31 Aug 2017 04:29:51 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:29:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Content-ID header field in Session Initiation Protocol (SIP) Authors : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-content-id-08.txt Pages : 15 Date : 2017-08-31 Abstract: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. This document updates RFC 5368 and RFC 6442, by clarifying their usage of the SIP Content-ID header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-content-id-08 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-content-id-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 31 04:34:54 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4021B132D5F; Thu, 31 Aug 2017 04:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDzvdB6_Tqla; Thu, 31 Aug 2017 04:34:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BE5132D5A; Thu, 31 Aug 2017 04:34:37 -0700 (PDT) X-AuditID: c1b4fb30-597ff70000005897-9f-59a7f44c4ca9 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.12.22679.C44F7A95; Thu, 31 Aug 2017 13:34:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 13:34:35 +0200 From: Christer Holmberg To: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" , Ben Campbell Thread-Topic: Draft new version: draft-content-id-08 Thread-Index: AQHTIk0fBOaYl9hyqUawFEXfvu4Y7w== Date: Thu, 31 Aug 2017 11:34:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D5CDD00A20D54christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7ga7Pl+WRBlPXiFrs+buI3WJ+52l2 i9NfZzBZrHh9jt1ixp+JzBYNnStZLXo/L2S2+PpjE5sDh8eSJT+ZPGbtfMLiMflxG3MAcxSX TUpqTmZZapG+XQJXxs2eFSwFb7wrPk2YzNzA+Nepi5GTQ0LAROJuyw6WLkYuDiGBI4wS7XuX M0M4SxglDq5+DuRwcLAJWEh0/9MGiYsI3GaSONG4nhGkW1hAX2Lr96UsILYI0KTbi7+yQ9h6 Em/23GADsVkEVCVOvJvECmLzClhLbDuyCqyeUUBM4vupNUwgNrOAuMStJ/OZIC4SkFiy5zwz hC0q8fLxP1aQG0SBZr7b7wkRVpS4On05VGuCxJ7nF5khxgtKnJz5hGUCo9AsJFNnISmbhaQM Iq4jsWD3JzYIW1ti2cLXzDD2mQOPoXqtJW7uPcuIrGYBI8cqRtHi1OKk3HQjI73Uoszk4uL8 PL281JJNjMAoPLjlt8EOxpfPHQ8xCnAwKvHwvr65PFKINbGsuDL3EKMEB7OSCO+CD0Ah3pTE yqrUovz4otKc1OJDjNIcLErivI77LkQICaQnlqRmp6YWpBbBZJk4OKUaGJOPm3Q3coXZ9n5U S54a+SxJVMZ6kryYJ3vMOW+D/KfuU/7+XaySOM+7zboo+u0lx30xvI+rLcruTJ188eyZBwUL d/iovDF3rT+w2Wy/3dK1SYJH5OeH3Qq499ZybsZZ3y/n/SbqT5fvqJPwyvDrqW6d1x36iSFb V6bjYvlm4Sl7p9/PtY8rUGIpzkg01GIuKk4EAArVKLW+AgAA Archived-At: Subject: [sipcore] Draft new version: draft-content-id-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:34:45 -0000 --_000_D5CDD00A20D54christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the IESG reviews, we have submitted a new version (-08) of draft-c= ontent-id. Note that we did NOT include any update to RFC 6080, because we double-chec= ked the RFC6080 usage of Content-ID header field and we believe that: - RFC6080 does NOT use the *SIP* Content-ID header; and - RFC6080 does NOT need to use the *SIP* Content-ID header. Reasons: RFC6080 uses Content-ID heaer field as follows: --------------- For profile data delivered via content indirection, i.e., a pointer to a PCC, then the Content-ID MIME header, as described in [RFC4483], MUST be used for each profile document URI. --------------- and gives example as follows: --------------- NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB @192.168.1.44 SIP/2.0 Event: ua-profile;effective-by=3D3600 From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com ;tag=3Dabca To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com ;tag=3D1234 Call-ID: 3573853342923422@192.0.2.44 CSeq: 322 NOTIFY Via: SIP/2.0/UDP 192.0.2.3; branch=3Dz9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 MIME-Version: 1.0 Content-Type: message/external-body; access-type=3D"URL"; expiration=3D"Mon, 01 Jan 2010 09:00:00 UTC"; URL=3D"http://example.com/z100-000000000000.html"; size=3D9999; hash=3D10AB568E91245681AC1B Content-Type: application/x-z100-device-profile Content-ID: <39EHF78SA@example.com> --------------- The Content-ID header field above is NOT a *SIP* header field since it is p= laced *after* CRLF. The Content-ID header field above is a part of the message-body. Since the message-body is of message/external-body MIME type the semantic o= f the Content-ID header field above follows RFC2046 section 5.2.3 and RFC4483 section 5.6 - i.e. the Content-ID header = field above is a MIME header field and is used by UAS to determine whether the content fetched from http://example.com/z100-0= 00000000000.html has changed between UAC sending the SIP NOTIFY message and UAS receiving the SIP NOTIFY message= . Regards, Christer --_000_D5CDD00A20D54christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <791691DEF00CD34AB2A7B8823C76C770@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on the IESG reviews, we have submitted a new version (-08) of draft-c= ontent-id.

Note that we did NOT include any upd= ate to RFC 6080, because we double-checked the RFC6080&nbs= p;
usage of Content-ID header field and we believe that:

- RFC6080 does NOT use the *S= IP* Content-ID header; and
- RFC6080 does NOT need to us= e the *SIP* Content-ID header.

Reasons:

RFC6080 uses Content-ID heaer= field as follows:

---------------
   For profile data= delivered via content
   indirection, i.e= ., a pointer to a PCC, then the Content-ID MIME
   header, as descr= ibed in [RFC4483], MUST be used for each profile
   document URI.
---------------
and gives example as follows:=
---------------
NOTIFY sip:urn%3auuid%3a00000= 000-0000-1000-0000-00FF8D82EDCB
     = ;   @192.168.1.44 SIP/2.0
Event: ua-profile;effective-b= y=3D3600
     = ;  ;tag=3Dabca
     ;tag= =3D1234
CSeq: 322 NOTIFY
Via: SIP/2.0/UDP 192.0.2.3;
   branch=3Dz9hG4bK= 1e3effada91dc37fd5a0c95cbf6767d0
MIME-Version: 1.0
Content-Type: message/externa= l-body; access-type=3D"URL";
     = ;          expiration=3D"= Mon, 01 Jan 2010 09:00:00 UTC";
     = ;          URL=3D"http://example.com/z100-0000= 00000000.html";
     = ;          size=3D9999;
     = ;          hash=3D10AB568E9124= 5681AC1B

Content-Type: application/x-z= 100-device-profile
Content-ID: <39EHF78SA@example.com>
---------------

The Content-ID header field a= bove is NOT a *SIP* header field since it is placed *after* CRLF.

The Content-ID header field a= bove is a part of the message-body.

Since the message-body is of = message/external-body MIME type the semantic of the Content-ID header field= above follows 
RFC2046 section 5.2.3 and RFC= 4483 section 5.6 - i.e. the Content-ID header field above is a MIME header = field and is used by 
UAS to determine whether the = content fetched from http://example.com/z100-000000000000.html has changed between=  
UAC sending the SIP NOTIFY me= ssage and UAS receiving the SIP NOTIFY message.


Regards,

Christer
--_000_D5CDD00A20D54christerholmbergericssoncom_-- From nobody Thu Aug 31 09:47:15 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254D6132A8E; Thu, 31 Aug 2017 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvI82FI7v7gK; Thu, 31 Aug 2017 09:47:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A624132025; Thu, 31 Aug 2017 09:47:06 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7VGkx57083942 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Aug 2017 11:46:59 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" , Ben Campbell References: From: Adam Roach Message-ID: <91cf914a-20de-398e-2a6c-cc5761864495@nostrum.com> Date: Thu, 31 Aug 2017 11:46:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2F9B43B1041066C4103396A0" Content-Language: en-US Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 16:47:08 -0000 This is a multi-part message in MIME format. --------------2F9B43B1041066C4103396A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/31/17 06:34, Christer Holmberg wrote: > - RFC6080 does NOT use the *SIP* Content-ID header; and > - RFC6080 does NOT need to use the *SIP* Content-ID header. Thanks. Your analysis looks correct to me. /a --------------2F9B43B1041066C4103396A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 8/31/17 06:34, Christer Holmberg wrote:
- RFC6080 does NOT use the *SIP* Content-ID header; and
- RFC6080 does NOT need to use the *SIP* Content-ID header.


Thanks. Your analysis looks correct to me.

/a

--------------2F9B43B1041066C4103396A0-- From nobody Thu Aug 31 14:27:48 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E33132027; Thu, 31 Aug 2017 14:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji7LVfsXhqFN; Thu, 31 Aug 2017 14:27:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAED2120720; Thu, 31 Aug 2017 14:27:44 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7VLRbL5032299 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Aug 2017 16:27:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 31 Aug 2017 16:27:37 -0500 Cc: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christer Holmberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 21:27:47 -0000 Hi, I=E2=80=99m a little confused by the new text in section 1.6. = (Apologies, I realize that you proposed that text in email, but I = somehow missed it at the time.) > 1.6. Backward compatibility >=20 > If an existing specification explicitly defines the usage of a > multipart message-body for carrying a single body part, that > specification MUST be updated in order to allow usage of a non- > multipart message-body for carrying the MIME entity, and for > referencing the whole message-body using a Content-ID URL. >=20 Is the point of that to simply say that an update must occur, or that = implementations cannot use a non-multipart body unless such an update = occurs? If the former, I suggest dropping the normative language, for = example by replacing =E2=80=9CMUST be=E2=80=9D with =E2=80=9Cshould = be=E2=80=9D, since we can=E2=80=99t really make people update a = specification, If the latter, I propose the following: "If an existing specification only defines the usage of a multipart message-body for carrying a single body part to be = referenced by a Content-ID URL, , implementations MUST NOT carry the MIME entity in a non-multipart message-body unless the specification is updated to explicitly allow it.=E2=80=9D Ben. > On Aug 31, 2017, at 6:34 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > Based on the IESG reviews, we have submitted a new version (-08) of = draft-content-id. >=20 > Note that we did NOT include any update to RFC 6080, because we = double-checked the RFC6080=20 > usage of Content-ID header field and we believe that: >=20 > - RFC6080 does NOT use the *SIP* Content-ID header; and > - RFC6080 does NOT need to use the *SIP* Content-ID header. >=20 > Reasons: >=20 > RFC6080 uses Content-ID heaer field as follows: >=20 > --------------- > For profile data delivered via content > indirection, i.e., a pointer to a PCC, then the Content-ID MIME > header, as described in [RFC4483], MUST be used for each profile > document URI. > --------------- > and gives example as follows: > --------------- > NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB > @192.168.1.44 SIP/2.0 > Event: ua-profile;effective-by=3D3600 > From: = sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com > ;tag=3Dabca > To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com > ;tag=3D1234 > Call-ID: 3573853342923422@192.0.2.44 > CSeq: 322 NOTIFY > Via: SIP/2.0/UDP 192.0.2.3; > branch=3Dz9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 > MIME-Version: 1.0 > Content-Type: message/external-body; access-type=3D"URL"; > expiration=3D"Mon, 01 Jan 2010 09:00:00 UTC"; > URL=3D"http://example.com/z100-000000000000.html"; > size=3D9999; > hash=3D10AB568E91245681AC1B >=20 > Content-Type: application/x-z100-device-profile > Content-ID: <39EHF78SA@example.com> > --------------- >=20 > The Content-ID header field above is NOT a *SIP* header field since it = is placed *after* CRLF. >=20 > The Content-ID header field above is a part of the message-body. >=20 > Since the message-body is of message/external-body MIME type the = semantic of the Content-ID header field above follows=20 > RFC2046 section 5.2.3 and RFC4483 section 5.6 - i.e. the Content-ID = header field above is a MIME header field and is used by=20 > UAS to determine whether the content fetched from = http://example.com/z100-000000000000.html has changed between=20 > UAC sending the SIP NOTIFY message and UAS receiving the SIP NOTIFY = message. >=20 >=20 > Regards, >=20 > Christer From nobody Thu Aug 31 22:59:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBFC132FAF; Thu, 31 Aug 2017 22:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPI5B4f1McfL; Thu, 31 Aug 2017 22:59:50 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313171330D0; Thu, 31 Aug 2017 22:59:46 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-ff-59a8f750687d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 13.CF.21299.057F8A95; Fri, 1 Sep 2017 07:59:45 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 07:59:44 +0200 From: Christer Holmberg To: Ben Campbell CC: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Thread-Topic: Draft new version: draft-content-id-08 Thread-Index: AQHTIk0fBOaYl9hyqUawFEXfvu4Y76Ke2c2AgADCpwA= Date: Fri, 1 Sep 2017 05:59:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <78144F7D4A12BA4BBB8E5753D996A72B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2K7mW7g9xWRBocPclrs+buI3WJ+52l2 i9NfZzBZrHh9jt1ixp+JzBYNnStZLXo/L2S2+PpjE5sDh8eSJT+ZPGbtfMLiMflxG3MAcxSX TUpqTmZZapG+XQJXxuoTGxkLnshVfF92mbGB8YJEFyMnh4SAicTqr8+Yuxi5OIQEjjBKdO36 xA7hLGaUWL5vM0sXIwcHm4CFRPc/bZAGEQEliefNW1lAbGaBnUwSyzvkQGxhAWOJxrczGCFq TCRuL/7KDmFbSVyYB1HPIqAicfVOO5jNK2AtMenUBiYQW0igQGJR73VmEJtTwF7iw9HPYL2M AmIS30+tYYLYJS5x68l8JoijBSSW7DnPDGGLSrx8/I8V5ExRAT2Jd/s9QUwJAUWJ5f1yEJ16 EjemTmGDsK0lFu05AzVRW2LZwtfMENcISpyc+YRlAqP4LCTLZiFpn4WkfRaS9llI2hcwsq5i FC1OLU7KTTcy1kstykwuLs7P08tLLdnECIzYg1t+q+5gvPzG8RCjAAejEg/v1f4VkUKsiWXF lbmHGCU4mJVEeJs/A4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOu67ECEkkJ5YkpqdmlqQWgST ZeLglGpg9Nc7YzN/+dn9bF+kTqasVTYwevnzyMXXERofOZ+Lr9vIJyD6tq0hSkCddW+YyszQ 11WM3gYey/x23nj8pKfV+d9+n4OrewWLNZfwvuFP0X+4RyLrR3RTwnfJ59Us1lpc/vET01Vn Pz3GPvvOrzNn6tTm1f+Z9Df9XtN03W3v5JJ3fIx8NXvyESWW4oxEQy3mouJEAOrSXUbUAgAA Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 05:59:52 -0000 Hi, >I=B9m a little confused by the new text in section 1.6. (Apologies, I >realize that you proposed that text in email, but I somehow missed it at >the time.) Don=B9t worry - some of the text suggested on the list has been slightly modified, based on input from Ivo etc :) >> 1.6. Backward compatibility >>=20 >> If an existing specification explicitly defines the usage of a >> multipart message-body for carrying a single body part, that >> specification MUST be updated in order to allow usage of a non- >> multipart message-body for carrying the MIME entity, and for >> referencing the whole message-body using a Content-ID URL. >>=20 > > >Is the point of that to simply say that an update must occur, or that >implementations cannot use a non-multipart body unless such an update >occurs? If the former, I suggest dropping the normative language, for >example by replacing =B3MUST be=B2 with =B3should be=B2, since we can=B9t = really >make people update a specification, > >If the latter, I propose the following: > > "If an existing specification only defines the usage of a > multipart message-body for carrying a single body part to be referenced > by a Content-ID URL, , implementations MUST NOT carry the MIME entity > in a non-multipart message-body unless the specification is updated > to explicitly allow it.=B2 Works for me. Regards, Christer > >> On Aug 31, 2017, at 6:34 AM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >> Based on the IESG reviews, we have submitted a new version (-08) of >>draft-content-id. >>=20 >> Note that we did NOT include any update to RFC 6080, because we >>double-checked the RFC6080 >> usage of Content-ID header field and we believe that: >>=20 >> - RFC6080 does NOT use the *SIP* Content-ID header; and >> - RFC6080 does NOT need to use the *SIP* Content-ID header. >>=20 >> Reasons: >>=20 >> RFC6080 uses Content-ID heaer field as follows: >>=20 >> --------------- >> For profile data delivered via content >> indirection, i.e., a pointer to a PCC, then the Content-ID MIME >> header, as described in [RFC4483], MUST be used for each profile >> document URI. >> --------------- >> and gives example as follows: >> --------------- >> NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB >> @192.168.1.44 SIP/2.0 >> Event: ua-profile;effective-by=3D3600 >> From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com >> ;tag=3Dabca >> To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com >> ;tag=3D1234 >> Call-ID: 3573853342923422@192.0.2.44 >> CSeq: 322 NOTIFY >> Via: SIP/2.0/UDP 192.0.2.3; >> branch=3Dz9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 >> MIME-Version: 1.0 >> Content-Type: message/external-body; access-type=3D"URL"; >> expiration=3D"Mon, 01 Jan 2010 09:00:00 UTC"; >> URL=3D"http://example.com/z100-000000000000.html"; >> size=3D9999; >> hash=3D10AB568E91245681AC1B >>=20 >> Content-Type: application/x-z100-device-profile >> Content-ID: <39EHF78SA@example.com> >> --------------- >>=20 >> The Content-ID header field above is NOT a *SIP* header field since it >>is placed *after* CRLF. >>=20 >> The Content-ID header field above is a part of the message-body. >>=20 >> Since the message-body is of message/external-body MIME type the >>semantic of the Content-ID header field above follows >> RFC2046 section 5.2.3 and RFC4483 section 5.6 - i.e. the Content-ID >>header field above is a MIME header field and is used by >> UAS to determine whether the content fetched from >>http://example.com/z100-000000000000.html has changed between >> UAC sending the SIP NOTIFY message and UAS receiving the SIP NOTIFY >>message. >>=20 >>=20 >> Regards, >>=20 >> Christer >