<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!-- Normative References -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!-- MUST, SHOULD, MAY -->
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC4475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4475.xml">
<!-- HTTP -->
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!-- SDP -->
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!-- TLS -->
<!ENTITY RFC6455 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml">
<!-- Websocket Protocol -->
<!ENTITY RFC6872 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6872.xml">
<!-- SIP CLF Data Model -->
<!ENTITY RFC6873 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6873.xml">
<!-- SIP CLF Format -->
<!ENTITY RFC7118 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7118.xml">
<!-- SIP WenSocket Transport -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc tocappendix="yes" ?>
<rfc category="std" docName="draft-salgueiro-dispatch-websocket-sipclf-00"
     ipr="trust200902" updates="6873">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="WebSocket Transport in SIP CLF">Indicating
    WebSocket Protocol as a Transport in the Session Initiation
    Protocol (SIP) Common Log Format (CLF)</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Gonzalo Salgueiro" initials="G.S."
            surname="Salgueiro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>

          <city>Research Triangle Park</city>

          <region>NC</region>

          <code>27709</code>

          <country>US</country>
        </postal>

        <email>gsalguei@cisco.com</email>
      </address>
    </author>

    <author fullname="Victor Pascual" initials="V.P."
            surname="Pascual">
      <organization>Quobis</organization>

      <address>
        <email>victor.pascual@quobis.com</email>
      </address>
    </author>

    <author fullname="Ant&oacute;n Rom&aacute;n" initials="A.R."
            surname="Rom&aacute;n">
      <organization>Quobis</organization>

      <address>
        <email>anton.roman@quobis.com</email>
      </address>
    </author>

    <author fullname="Sergio Garcia Ramos" initials="S.G.R."
            surname="Garcia">
      <organization>Quobis</organization>

      <address>
        <email>sergio.garcia@quobis.com</email>
      </address>
    </author>

    <date year="2014"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
         in the current day and month for you. If the year is not the current one, it is
         necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
         purpose of calculating the expiry date).  With drafts it is normally sufficient to
         specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>IETF</area>

    <workgroup>DISPATCH Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
         If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>SIP CLF</keyword>

    <keyword>CLF</keyword>

    <keyword>SIP</keyword>

    <keyword>WebSocket</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>RFC 7118 <xref
      target="RFC7118"/> specifies a WebSocket
      sub-protocol as a reliable real-time transport mechanism between
      SIP (Session Initiation Protocol) entities to enable usage of
      SIP in web-oriented deployments. This document updates the SIP
      Common Log Format (CLF), defined in RFC 6873 <xref
      target="RFC6873"/>, with a new "Transport Flag" for such SIP
      WebSocket transport.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The WebSocket protocol <xref target="RFC6455"/> enables
      two-way message exchange between clients and servers on top of a
      persistent TCP connection (optionally secured with TLS <xref
      target="RFC5246"/>). The initial protocol handshake makes use of
      HTTP <xref target="RFC2616"/> semantics, allowing the WebSocket
      protocol to reuse existing HTTP infrastructure.</t>

      <t>RFC 7118 <xref
      target="RFC7118"/> defines a WebSocket
      sub-protocol for transporting SIP messages between a WebSocket
      client and server.</t>

      <t>SIP messages can be logged using the Common Log Format defined                   
      in RFC 6873 <xref target="RFC6873"/>.  In order to make such SIP 
      CLF logging possible for SIP messages transported over the 
      WebSocket protocol, a new WebSocket "Transport Flag" ('W') must be 
      added to the "Transport Flags" already defined in RFC 6873 
      <xref target="RFC6873"/> (i.e., UDP, TCP and SCTP).</t>

      <t>This document updates RFC 6873 <xref target="RFC6873"/> by
      defining a new SIP CLF "Transport Flag" value for WebSocket.</t>
    </section>

    <section anchor="terminology" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described
      in <xref target="RFC2119"/>.</t>
    </section>

    <section anchor="conventions" title="Document Conventions">
      <t>This document details several examples of SIP CLF records 
      showing messages over plain and secure WebSocket connections. The 
      formatting described in this document does not permit the examples 
      to be unambiguously rendered due to the constraints imposed by the 
      formatting rules for RFCs.  To avoid ambiguity and to meet the RFC 
      layout requirements, this document uses the &lt;allOneLine/&gt; 
      markup convention established in <xref target="RFC4475"/>. This 
      markup convention is described in detail in Section 3 of RFC 6873 
      <xref target="RFC6873"/> and used throughout that document for 
      representing the syntax of SIP CLF records.</t>
    </section>

    <section anchor="usage"
             title="Usage of the Websocket Transport Flag">
      <t>Section 4.2 of RFC6873 <xref target="RFC6873"/> specifies the 
      mandatory fields in a SIP CLF record.  The fourth and fifth bytes 
      of the five byte "Flags Field" are the "Transport Flag" and the 
      "Encryption Flag" respectively.  SIP messages transported over 
      both a plain and secure WebSocket connection can be completely and 
      uniquely represented by appropriately setting these two flag 
      fields.</t>
   
      <t>The currently registered values of the "Transport Flag" 
      (Section 9.2 of RFC 6873) are [UDP ('U'), TCP ('T'), and SCTP 
      ('S')].  This document defines and registers a new "Transport 
      Flag" value 'W' for WebSocket transport of SIP messages and 
      consequently updates RFC 6873 <xref target="RFC6873"/> and the 
      IANA "SIP CLF Transport Flag Values" registry.</t>
   
     <t>SIP CLF records of messages transported over a plain WebSocket 
     connection (WS) MUST set the "Transport Flag" to this new 'W' value 
     and the "Encryption Flag" value to 'U' (Unencrypted). SIP CLF 
     records of messages transported over a secure WebSocket (WSS) 
     connection (i.e. WS over TLS) MUST set the "Transport Flag" to this 
     new 'W' value and the "Encryption Flag" value to 'E' 
     (Encrypted).</t>
    </section>

    <section anchor="examples" title="Examples">
      <t>The following examples show sample SIP CLF records logged for 
      SIP messages transported over both plain and secure WebSocket 
      connections.</t>

      <section anchor="WS" title="SIP over WebSocket (WS)">
        <t>The following example represents a SIP INVITE request sent
        over a plain WebSocket connection.  For the sake of brevity, the 
        Session Description Protocol (SDP) <xref target="RFC4566"/> body 
        is omitted.
        <figure>
            <artwork><![CDATA[
            
    INVITE sip:bob@example.com SIP/2.0
    Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
    From: sip:alice@example.com;tag=asdyka899
    To: sip:bob@example.com
    Call-ID: asidkj3ss
    CSeq: 1 INVITE
    Max-Forwards: 70
    Date: Thu, 6 Feb 2014 15:02:03 GMT
    Supported: path, outbound, gruu
    Route: <sip:proxy.example.com:80;transport=ws;lr>
    Contact: <sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob>
    Content-Type: application/sdp
    Content-Length: 418

      ]]></artwork>
          </figure>
        Shown below is approximately how this message would appear
        as a single record in a SIP CLF logging file if encoded
        according to the syntax described in <xref target="RFC6873"/>. 
        Due to RFC conventions, this log entry has been split into five 
        lines, instead of the two lines that actually appear in a log 
        file; and the Tab characters have been padded out using spaces 
        to simulate their appearance in a text terminal.
          <figure>
            <artwork><![CDATA[
            
    A0000E7,0053005C005E00720080009200A600A800BE00C800D200DE00E7
    <allOneLine>
    1328821153.010    RORWU    1 INVITE    -    sip:bob@example.com
    192.0.2.10:80    192.0.2.200:56485    sip:bob@example.com    -    
    sip:alice@example.com    asdyka899    asidkj3ss    S1781761-88    
    C67651-11
    </allOneLine>
    
      ]]></artwork>
          </figure>A bit-exact version of the actual log entry is provided here, Base64 encoded.

      <figure>
      <artwork align="left"><![CDATA[

    begin-base64 644 clf_ws_record
    QTAwMDBFNywwMDUzMDA1QzAwNUUwMDcyMDA4MDAwOTIwMEE2MDBBODAwQkUwMEM4MDBE
    MjAwREUwMEU3CjEzMjg4MjExNTMuMDEwCVJPUldVCTEgSU5WSVRFCS0Jc2lwOmJvYkBl
    eGFtcGxlLmNvbQkxOTIuMC4yLjEwOjgwCTE5Mi4wLjIuMjAwOjU2NDg1CXNpcDpib2JA
    ZXhhbXBsZS5jb20JLQlzaXA6YWxpY2VAZXhhbXBsZS5jb20JYXNkeWthODk5CWFzaWRr
    ajNzcwlTMTc4MTc2MS04OAlDNjc2NTEtMTEKCg==
    ====
    
      ]]></artwork>
          </figure></t>
      </section>

      <section anchor="WSS" title="SIP over Secure WebSocket (WSS)">
        <t>The following example represents a SIP INVITE request sent 
        over a secure WebSocket connection (i.e., WebSocket over TLS 
        <xref target="RFC5246"/>). For the sake of brevity, the SDP body 
        is omitted.
        
        <figure>
        <artwork><![CDATA[
            
    INVITE sip:bob@example.com SIP/2.0
    Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
    From: sip:alice@example.com;tag=asdyka899
    To: sip:bob@example.com
    Call-ID: asidkj3ss
    CSeq: 1 INVITE
    Max-Forwards: 70
    Date: Thu, 6 Feb 2014 15:02:03 GMT
    Supported: path, outbound, gruu
    Route: <sip:proxy.example.com:443;transport=ws;lr>
    Contact: <sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob>
    Content-Type: application/sdp
    Content-Length: 439
        
      ]]></artwork>
          </figure>

        Shown below is approximately how this message would appear
        as a single record in a SIP CLF logging file if encoded
        according to the syntax described in <xref target="RFC6873"/>. 
        Due to RFC conventions, this log entry has been split into five 
        lines, instead of the two lines that actually appear in a log 
        file; and the Tab characters have been padded out using spaces 
        to simulate their appearance in a text terminal.

        <figure>
            <artwork><![CDATA[
            
    A0000E8,0053005C005E00720081009300A700A900BF00C900D300DF00E8
    <allOneLine>
    1328821153.010    RORWE    1 INVITE    -    sip:bob@example.com
    192.0.2.10:443    192.0.2.200:56485    sip:bob@example.com    -    
    sip:alice@example.com:5060    asdyka899    asidkj3ss    S1781761-88    
    C67651-11
    </allOneLine>
        
      ]]></artwork>
          </figure>

        A bit-exact version of the actual log entry is provided here, Base64 encoded.

        <figure>
            <artwork><![CDATA[
            
    begin-base64 644 clf_ws_record
    QTAwMDBFOCwwMDUzMDA1QzAwNUUwMDcyMDA4MTAwOTMwMEE3MDBBOTAwQkYwMEM5MDBE
    MzAwREYwMEU4CjEzMjg4MjExNTMuMDEwCVJPUldVCTEgSU5WSVRFCS0Jc2lwOmJvYkBl
    eGFtcGxlLmNvbQkxOTIuMC4yLjEwOjQ0MwkxOTIuMC4yLjIwMDo1NjQ4NQlzaXA6Ym9i
    QGV4YW1wbGUuY29tCS0Jc2lwOmFsaWNlQGV4YW1wbGUuY29tCWFzZHlrYTg5OQlhc2lk
    a2ozc3MJUzE3ODE3NjEtODgJQzY3NjUxLTExCgo=
    ====
        
      ]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="security_considerations"
             title="Security Considerations">
      <t>This document merely adds a new "Transport Flag" value for
      the WebSocket protocol. This value may be set in a SIP CLF
      record, but its use does not intrinsically introduce and new
      security considerations. When logging protocol information, such
      as with SIP CLF, there are a myriad of security, privacy and
      data protection to consider. These are exhaustively described in
      RFC 6872 <xref target="RFC6872"/> and RFC 6873 <xref
      target="RFC6873"/>.</t>

      <t>Any security considerations specific to the WebSocket
      protocol or its application as a transport for SIP are detailed
      in the relevant specifications (RFC 6455 <xref
      target="RFC6455"/> and draft-ietf-sipcore-sip-websocket <xref
      target="RFC7118"/>) and are considered
      outside the scope of this document.</t>
    </section>

    <section anchor="iana_considerations" title="IANA Considerations">
      <t>This document defines a new value ('W') for SIP CLF
      "Transport Flag" and requests IANA to register this value in the
      registry titled "SIP CLF Transport Flag Values", as shown in
      <xref target="transport_table"/> below.</t>

      <texttable anchor="transport_table"
                 title="IANA-Registered SIP CLF Transport Flag">
        <ttcol align="center">Value</ttcol>

        <ttcol align="center">Transport Protocol</ttcol>

        <ttcol align="center">Reference</ttcol>

        <c>W</c>

        <c>WebSocket</c>

        <c>RFC&rfc.number;</c>

        <postamble/>
      </texttable>

      <t>[[NOTE TO RFC EDITOR: Please change &rfc.number; to the
      number assigned to this specification, and remove this paragraph
      on publication.]]</t>
    </section>

    <section anchor="acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">

      &RFC2119;

      &RFC6455;

      &RFC6872;

      &RFC6873;

      &RFC7118;

    </references>

    <references title="Informative References">
      &RFC2616;

      &RFC4475;
      
      &RFC4566;

      &RFC5246;
    </references>
  </back>
</rfc>
