[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                           C. Wendt
Internet-Draft                                                   Comcast
Intended status: Standards Track                             J. Peterson
Expires: January 14, 2021                                   Neustar Inc.
                                                           July 13, 2020


              SIP Call-Info Parameters for Rich Call Data
                  draft-wendt-sipcore-callinfo-rcd-03

Abstract

   This document describes a SIP Call-Info header field usage defined to
   include rich data associated with the identity of the calling party
   that can be rendered to called party for providing more useful
   information about the caller or the specific reason for the call.
   This includes extended comprehensive information about the caller
   such as what a jCard object can represent for describing the calling
   party or other call specific information such as describing the
   reason or intent of the call.  The elements defined for this purpose
   are intended to be extensible to accommodate related information
   about calls that helps people decide whether to pick up the phone and
   additionally, with the use of jCard and other elements, to be
   compatible with the STIR/PASSporT Rich Call Data framework.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 14, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Wendt & Peterson        Expires January 14, 2021                [Page 1]


Internet-Draft          Call-Info Rich Call Data               July 2020


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . .   4
   5.  'call-reason' Call-Info Parameter . . . . . . . . . . . . . .   6
   6.  Usage of jCard and property specific usage  . . . . . . . . .   7
     6.1.  Identification properties . . . . . . . . . . . . . . . .   7
       6.1.1.  "fn" property . . . . . . . . . . . . . . . . . . . .   7
       6.1.2.  "n" property  . . . . . . . . . . . . . . . . . . . .   8
       6.1.3.  "nickname" property . . . . . . . . . . . . . . . . .   8
       6.1.4.  "photo" property  . . . . . . . . . . . . . . . . . .   8
     6.2.  Delivery Addressing Properties  . . . . . . . . . . . . .   8
       6.2.1.  "adr" property  . . . . . . . . . . . . . . . . . . .   8
     6.3.  Communications Properties . . . . . . . . . . . . . . . .   9
       6.3.1.  "tel" property  . . . . . . . . . . . . . . . . . . .   9
       6.3.2.  "email" property  . . . . . . . . . . . . . . . . . .   9
       6.3.3.  "lang" property . . . . . . . . . . . . . . . . . . .   9
     6.4.  Geographical Properties . . . . . . . . . . . . . . . . .  10
       6.4.1.  "tz" property . . . . . . . . . . . . . . . . . . . .  10
       6.4.2.  "geo" property  . . . . . . . . . . . . . . . . . . .  10
     6.5.  Organizational Properties . . . . . . . . . . . . . . . .  10
       6.5.1.  "title" property  . . . . . . . . . . . . . . . . . .  10
       6.5.2.  "role" property . . . . . . . . . . . . . . . . . . .  10
       6.5.3.  "logo" property . . . . . . . . . . . . . . . . . . .  11
       6.5.4.  "org" property  . . . . . . . . . . . . . . . . . . .  11
     6.6.  Explanatory Properties  . . . . . . . . . . . . . . . . .  11
       6.6.1.  "catagories" property . . . . . . . . . . . . . . . .  11
       6.6.2.  "note" property . . . . . . . . . . . . . . . . . . .  11
       6.6.3.  "sound" property  . . . . . . . . . . . . . . . . . .  12
       6.6.4.  "uid" property  . . . . . . . . . . . . . . . . . . .  12
       6.6.5.  "url" property  . . . . . . . . . . . . . . . . . . .  12
       6.6.6.  "version" property  . . . . . . . . . . . . . . . . .  12
   7.  Extension of jCard  . . . . . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  SIP Call-Info Header Field Purpose Token Request  . . . .  13



Wendt & Peterson        Expires January 14, 2021                [Page 2]


Internet-Draft          Call-Info Rich Call Data               July 2020


     9.2.  SIP Call-Info Header Field Purpose Token Request  . . . .  13
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     11.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Traditional telephone network signaling protocols have long supported
   delivering a 'calling name' from the originating side, though in
   practice, the terminating side is often left to derive a name from
   the calling party number by consulting a local address book or an
   external database.  SIP similarly can carry a 'display-name' in the
   From header field value from the originating to terminating side,
   though it is an unsecured field that is not commonly trusted.  The
   same is true of information in the Call-Info header field.

   To allow calling parties to initiate, and called parties to receive,
   a more comprehensive, deterministic, and extensible rich call data
   for incoming calls, we describe new tokens for the SIP [RFC3261]
   Call-Info header field and a corresponding "purpose" parameter.  We
   also define a new parameter of Call-Info designed for carrying a
   "reason" value.  For this document, depending on the policies of the
   communications system, calling parties could either be the end user
   device or an originating service provider, and called parties could
   also similarly be an end user device or the terminating service
   provider acting on behalf of the recipient of the call.

   Used on its own, this specification assumes that called party user
   agent can trust the SIP network or the SIP provider to deliver the
   correct rich call data (RCD) information.  This may not always be the
   case and thus, the entity inserting the Call-Info header field and
   the UAS relying on it SHOULD be part of the same trust domain
   [RFC3324].  Alternatively, and likely the recommended approach, is
   that the entity inserting the call-info header should also sign the
   caller information via STIR mechanisms [RFC8224] and specifically
   through the [I-D.ietf-stir-passport-rcd].  This STIR signature would
   likely be provided by the caller itself or the originating service
   provider using an authoritative signature to authenticate the
   information is from the originator and hasn't been tampered with in
   transmission.

   [RFC7852] provides a means of carrying additional data about callers
   for the purposes of emergency services (especially its Section 4.4
   "Owner/Subscriber" information).  This specification provides an
   overlapping functionality for non-emergency cases.  Rather than
   overloading its "EmergencyCallData" Call-Info "purpose" parameter



Wendt & Peterson        Expires January 14, 2021                [Page 3]


Internet-Draft          Call-Info Rich Call Data               July 2020


   value, this document defines a separate "purpose" parameter for the
   more generic delivery of information via jCard [RFC7095].  This
   document borrows from [RFC7852] the capability to carry a data
   structure as a body, through the use of the "cid" URI scheme
   [RFC2392].

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Overview

   The Call-Info header field, defined in [RFC3261] Section 20.9,
   defines a purpose parameter currently with "info", "icon", and "card"
   tokens.  This document defines one new purpose value and one new
   generic parameter for Call-Info.

   The value "jcard" is to be used to associate rich call data related
   to the identity of the calling party in the form of a jCard
   [RFC7095].  While there is a "card" token that is already defined
   with similar purpose, there are two primary reasons for the
   definition and usage of jCard and the use of JSON over the XML based
   vCard [RFC2426].  First, JSON has become the default and optimally
   supported for transmission, parsing, and manipulation of data on IP
   networks.  Second, jCard has also been defined in
   [I-D.ietf-stir-passport-rcd] and has been adopted by PASSporT
   [RFC8225] because of the usage of JSON Web Tokens (JWT) [RFC7519].

   A generic parameter for "call-reason" is to be used to provide a
   string or other object that is used to convey the intent or reason
   the caller is calling to help the called party understand better the
   context of the call and why they may want to answer the call.

4.  "jcard" Call-Info Token

   The use of the new Call-Info Token "jcard" is for the purpose of
   supporting RCD associated with the identity of a calling party in a
   SIP call [RFC3261] Section 20.9.  The format of a Call-Info header
   field when using the "jcard" is as follows.

   The Call-Info header should include a URI where the resource pointed
   to by the URI is a jCard JSON object defined in [RFC7095].  This MAY
   be carried in the body of the SIP request bearing this Call-Info via
   the "cid" URI scheme [RFC2392].  Alternatively, the URI MUST define



Wendt & Peterson        Expires January 14, 2021                [Page 4]


Internet-Draft          Call-Info Rich Call Data               July 2020


   the use HTTPS or a transport that can validate the integrity of the
   source of the resource as well as the transport channel the resource
   is retrieved.

   An example of a Call-Info header field is:

     Call-Info: <https://example.com/jbond.json>

   An example jCard JSON file is shown as follows:

  ["vcard",
    [
      ["version", {}, "text", "4.0"],
      ["fn", {}, "text", "James Bond"],
      ["n", {}, "text", ["Bond", "James", "", "", "Mr."]],
      ["adr", {"type":"work"}, "text",
        ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008",
        "USA"]
      ],
      ["email", {}, "text", "007@mi6-hq.com"],
      ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
        "tel:+1-202-555-1000"],
      ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"],
      ["bday", {}, "date", "19241116"]
      ["logo", {}, "uri",
      "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"]
    ]
  ]

   An example SIP INVITE using the "cid" URI scheme is as follows.





















Wendt & Peterson        Expires January 14, 2021                [Page 5]


Internet-Draft          Call-Info Rich Call Data               July 2020


INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
Call-Info: <cid:12155551212@example.com>;purpose=jcard;call-reason= \
  "For your ears only"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551212@gateway.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...

--boundary1

Content-Type: application/sdp

v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

--boundary1

Content-Type: application/vcard+json
Content-ID: <12155551212@example.com>

["vcard",[["version",{},"text","4.0"],["fn",{},"text","James Bond"
],["n",{},"text",["Bond","James","","","Mr."]],["adr",{"type":
"work"},"text",["","","3100 Massachusetts Avenue NW","Washington",
"DC","20008","USA"]],["email",{},"text","007@mi6-hq.com"],["tel",
{"type":["voice","text","cell"],"pref":"1"},"uri","tel:+1-202-555-1000"],
["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"],["bday",{},"date",
"19241116"]["logo",{},"uri","https://upload.wikimedia.org/wikipedia/en
/c/c5/Fleming007impression.jpg"]]]

5.  'call-reason' Call-Info Parameter

   In addition to the jCard value defined here, this specification also
   defines a generic parameter of the Call-Info header called "call-
   reason".  The "call-reason" parameter is intended to convey a short
   textual message suitable for display to an end user during call
   alerting.  As a general guideline, this message SHOULD be no longer
   than 160 characters; displays that support this specification may be



Wendt & Peterson        Expires January 14, 2021                [Page 6]


Internet-Draft          Call-Info Rich Call Data               July 2020


   forced to truncate messages that cannot fit onto a screen.  This
   message conveys the caller's intention in contacting the callee.  It
   is an optional parameter, and the sender of a SIP request cannot
   guarantee that its display will be supported by the terminating
   endpoint.  The manner in which this reason is set by the caller is
   outside the scope of this specification.

   One alternative approach would be to use the baseline [RFC3261]
   Subject header field value to convey the reason for the call.
   Because the Subject header has seen little historical use in SIP
   implementations, however, and its specification describes its
   potential use in filtering, it seems more prudent to define a new
   means of carrying a call reason indication.

   An example of a Call-Info header field value with the "call-reason"
   parameter follows:

Call-Info: <https://example.com/jbond.json>;call-reason="For your ears only"

   One can readily imagine a need for more structured call reason data
   that could be reliably processed automatically.  Future versions of
   this specification may explore ways to provide a structured data
   object in place of a textual string to support things like
   internationalization or categories of reason that can be parsed by
   machines.

6.  Usage of jCard and property specific usage

   Beyond the definition of the specific properties or JSON arrays
   associated with each property.  This specification defines a few
   rules above and beyond [RFC7095] specific to making sure there is a
   mimimum level of supported properties that every implementation of
   this specification should adhere to.  This includes the support of
   intepreting the value of this property and the ability to render in
   some form appropriate to the display capabilities of the device.
   This includes requirements specific to either textual displays and
   graphics capable displays.

6.1.  Identification properties

   These types are used to capture information associated with the
   identification and naming of the entity associated with the jCard.

6.1.1.  "fn" property

   The "fn" property MUST be supported with the intent of providing a
   formatted text corresponding to the name of the object the jCard
   represents.  Reference [RFC6350] Section 6.2.1.



Wendt & Peterson        Expires January 14, 2021                [Page 7]


Internet-Draft          Call-Info Rich Call Data               July 2020


   Example:
   ["fn", {}, "text", "Mr. John Q. Public\, Esq."]

6.1.2.  "n" property

   The "n" property SHOULD be supported with the intent of providing the
   components of the name of the object the jCard represents.  Reference
   [RFC6350] Section 6.2.2.

   Example:
   ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]
   ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]

6.1.3.  "nickname" property

   The "nickname" property SHOULD be supported with the intent of
   providing the text corresponding to the nickname of the object the
   jCard represents.  Reference [RFC6350] Section 6.2.3.

   Example:
   ["nickname", {}, "text", "Robbie"]
   ["nickname", {}, "text", "Jim,Jimmie"]
   ["nickname", {}, "text", "TYPE=work:Boss"]

6.1.4.  "photo" property

   The "photo" property MUST be supported with the intent of an image or
   photograph information that annotates some aspect of the object the
   jCard represents.  Reference [RFC6350] Section 6.2.4.

   In addition to the definition of jCard, and to promote
   interoperability and proper formatting and rendering of images, the
   photo SHOULD correspond to a square image size of the sizes 128x128,
   256x256, 512x512, or 1024x1024 pixels.

  Example:
  ["photo", {}, "uri", "http://www.example.com/pub/photos/jqpublic.gif"]

6.2.  Delivery Addressing Properties

   These properties are concerned with information related to the
   delivery addressing or label for the jCard object.

6.2.1.  "adr" property

   The "adr" property MUST be supported with the intent of providing the
   delivery address of the object the jCard represents.  Reference
   [RFC6350] Section 6.3.1.



Wendt & Peterson        Expires January 14, 2021                [Page 8]


Internet-Draft          Call-Info Rich Call Data               July 2020


 Example:
 ["adr", {"type":"work"}, "text",
   ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008",
   "USA"]

6.3.  Communications Properties

   These properties describe information about how to communicate with
   the object the jCard represents.

6.3.1.  "tel" property

   The "tel" property MUST be supported with the intent of providing the
   telephone number for telephony communication of the object the jCard
   represents.  Reference [RFC6350] Section 6.4.1.

   Relative to the SIP From header field this information may provide
   alternate telephone number or other related telephone numbers for
   other uses.

   Example:
   ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
     "tel:+1-202-555-1000"]
   ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]

6.3.2.  "email" property

   The "email" property MUST be supported with the intent of providing
   the electronic mail address for communication of the object the jCard
   represents.  Reference [RFC6350] Section 6.4.2.

   Example:
   ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]
   ["email", {"pref":"1"}, "text", "jane_doe@example.com"]

6.3.3.  "lang" property

   The "lang" property MUST be supported with the intent of providing
   the language(s) that may be used for contacting of the object the
   jCard represents.  Reference [RFC6350] Section 6.4.4.

   Example:
   ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]
   ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]
   ["lang", {"type":"home"}, "language-tag", "fr"]






Wendt & Peterson        Expires January 14, 2021                [Page 9]


Internet-Draft          Call-Info Rich Call Data               July 2020


6.4.  Geographical Properties

   These properties are concerned with information associated with
   geographical positions or regions associated with the object the
   jCard represents.

6.4.1.  "tz" property

   The "tz" property MUST be supported with the intent of providing the
   time zone of the object the jCard represents.  Reference [RFC6350]
   Section 6.5.1.

   Note: Seems the up-to-date reference for where time-zone names are
   maintained is currently at this web address, https://www.iana.org/
   time-zones.

   Example:
   ["tz", {}, "text", "Raleigh/North America"]

6.4.2.  "geo" property

   The "geo" property MUST be supported with the intent of providing the
   global positioning of the object the jCard represents.  Reference
   [RFC6350] Section 6.5.2.

   Example:
   ["geo", {}, "uri", "geo:37.386013,-122.082932"]

6.5.  Organizational Properties

   These properties are concerned with information associated with
   characteristics of the organization or organizational units of the
   object that the jCard represents.

6.5.1.  "title" property

   The "title" property MUST be supported with the intent of providing
   the position or job of the object the jCard represents.  Reference
   [RFC6350] Section 6.6.1.

   Example:
   ["title", {}, "text", "Research Scientist"]

6.5.2.  "role" property

   The "role" property MUST be supported with the intent of providing
   the position or job of the object the jCard represents.  Reference
   [RFC6350] Section 6.6.2.



Wendt & Peterson        Expires January 14, 2021               [Page 10]


Internet-Draft          Call-Info Rich Call Data               July 2020


   Example:
   ["role", {}, "text", "Project Leader"]

6.5.3.  "logo" property

   The "logo" property MUST be supported with the intent of specifying a
   graphic image of a logo associated with the object the jCard
   represents.  Reference [RFC6350] Section 6.6.3.

   Example:
   ["logo", {}, "uri", "http://www.example.com/pub/logos/abccorp.jpg"]

   ["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC
         AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
         ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
         <...the remainder of base64-encoded data...>"]

6.5.4.  "org" property

   The "org" property MUST be supported with the intent of specifying
   the organizational name and units of the object the jCard represents.
   Reference [RFC6350] Section 6.6.2.

   Example:
   ["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]

6.6.  Explanatory Properties

   These properties are concerned with additional explanations, such as
   that related to informational notes or revisions specific to the
   jCard.

6.6.1.  "catagories" property

   The "catagories" property MUST be supported with the intent of
   specifying application category information the object the jCard
   represents.  Reference [RFC6350] Section 6.7.1.

Example:
["catagories", {}, "text", "TRAVEL AGENT"]

["catagories", {}, "text", "INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY"]

6.6.2.  "note" property

   The "note" property MUST be supported with the intent of specifying
   supplemental information or a comment the object the jCard
   represents.  Reference [RFC6350] Section 6.7.2.



Wendt & Peterson        Expires January 14, 2021               [Page 11]


Internet-Draft          Call-Info Rich Call Data               July 2020


   Example:
   ["note", {}, "text", "This fax number is operational 0800 to 1715
                EST\, Mon-Fri."]

6.6.3.  "sound" property

   The "sound" property MUST be supported with the intent of specifying
   a digital sound content information that annotates some aspect with
   the object the jCard represents.  This property is often used to
   specify the proper pronunciation of the name property value of the
   jCard.  Reference [RFC6350] Section 6.7.5.

   Example:
   ["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"]

   ["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE
         AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
         ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
         <...the remainder of base64-encoded data...>"]

6.6.4.  "uid" property

   The "uid" property MUST be supported with the intent of specifying a
   globally unique identifier corresponding to the object the jCard
   represents.  Reference [RFC6350] Section 6.7.6.

   Example:
   ["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]

6.6.5.  "url" property

   The "url" property MUST be supported with the intent of specifying a
   uniform resource locator associated to the object the jCard
   represents.  Reference [RFC6350] Section 6.7.8.

Example:
["url", {}, "uri", "https://example.org/restaurant.french/~chezchic.html"]

6.6.6.  "version" property

   The "version" property MUST be included and is intended to specify
   version of the vCard specification used to format this vCard.
   Reference [RFC6350] Section 6.7.9.

   Example:
   ["version", {}, "text", "4.0"]





Wendt & Peterson        Expires January 14, 2021               [Page 12]


Internet-Draft          Call-Info Rich Call Data               July 2020


7.  Extension of jCard

   Part of the intent of the usage of jCard is that it has it's own
   extensibility properties where new properties can be defined to relay
   newly defined information related to a caller.  This capability is
   inherently supported as part of standard extensibility.  However,
   usage of those new properties should be published and registered
   following [RFC7095] Section 3.6 or new specifications.

8.  Acknowledgements

   We would like to thank David Hancock and other members of the STIR
   working group for helpful suggestions and comments for the creation
   of this draft.

9.  IANA Considerations

9.1.  SIP Call-Info Header Field Purpose Token Request

   [this RFC] defines the "jcard" token for use as a new token in the
   Call-Info header in the "Header Field Parameters and Parameter
   Values" registry defined by [RFC3968].

      +--------------+----------------+-------------------+------------+
      | Header Field | Parameter Name | Predefined Values | Reference  |
      +--------------+----------------+-------------------+------------+
      | Call-Info    | jcard          | No                | [this RFC] |
      +--------------+----------------+-------------------+------------+

9.2.  SIP Call-Info Header Field Purpose Token Request

   [this RFC] defines the "call-reason" generic parameter for use as a
   new parameter in the Call-Info header in the "Header Field Parameters
   and Parameter Values" registry defined by [RFC3968].  The parameter's
   token is "call-reason" and it takes the value of a quoted string.

10.  Security Considerations

   Revealing information such as the name, location, and affiliation of
   a person necessarily entails certain privacy risks.  SIP and Call-
   Info has no particular confidentiality requirement, as the
   information sent in SIP is in the clear anyway.  Transport-level
   security can be used to hide information from eavesdroppers, and the
   same confidentiality mechanisms would protect any Call-Info or jCard
   information carried or referred to in SIP.






Wendt & Peterson        Expires January 14, 2021               [Page 13]


Internet-Draft          Call-Info Rich Call Data               July 2020


11.  References

11.1.  Normative References

   [I-D.ietf-stir-passport-rcd]
              Peterson, J. and C. Wendt, "PASSporT Extension for Rich
              Call Data", draft-ietf-stir-passport-rcd-06 (work in
              progress), March 2020.

   [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
              Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
              <https://www.rfc-editor.org/info/rfc2392>.

   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",
              RFC 2426, DOI 10.17487/RFC2426, September 1998,
              <https://www.rfc-editor.org/info/rfc2426>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC3324]  Watson, M., "Short Term Requirements for Network Asserted
              Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
              <https://www.rfc-editor.org/info/rfc3324>.

   [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Header Field Parameter Registry for the Session
              Initiation Protocol (SIP)", BCP 98, RFC 3968,
              DOI 10.17487/RFC3968, December 2004,
              <https://www.rfc-editor.org/info/rfc3968>.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              DOI 10.17487/RFC6350, August 2011,
              <https://www.rfc-editor.org/info/rfc6350>.

   [RFC6919]  Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
              for Use in RFCs to Indicate Requirement Levels", RFC 6919,
              DOI 10.17487/RFC6919, April 2013,
              <https://www.rfc-editor.org/info/rfc6919>.

   [RFC7095]  Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
              DOI 10.17487/RFC7095, January 2014,
              <https://www.rfc-editor.org/info/rfc7095>.






Wendt & Peterson        Expires January 14, 2021               [Page 14]


Internet-Draft          Call-Info Rich Call Data               July 2020


   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
              Telephone Identity Problem Statement and Requirements",
              RFC 7340, DOI 10.17487/RFC7340, September 2014,
              <https://www.rfc-editor.org/info/rfc7340>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7852]  Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
              J. Winterbottom, "Additional Data Related to an Emergency
              Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
              <https://www.rfc-editor.org/info/rfc7852>.

   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 8224,
              DOI 10.17487/RFC8224, February 2018,
              <https://www.rfc-editor.org/info/rfc8224>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/info/rfc8225>.

11.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Chris Wendt
   Comcast
   Comcast Technology Center
   Philadelphia, PA  19103
   USA

   Email: chris-ietf@chriswendt.net







Wendt & Peterson        Expires January 14, 2021               [Page 15]


Internet-Draft          Call-Info Rich Call Data               July 2020


   Jon Peterson
   Neustar Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520
   US

   Email: jon.peterson@neustar.biz












































Wendt & Peterson        Expires January 14, 2021               [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/