draft-ietf-sipcore-rejected-01.txt   draft-ietf-sipcore-rejected-02.txt 
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft Georgetown University Internet-Draft Georgetown University
Intended status: Standards Track November 25, 2018 Intended status: Standards Track December 28, 2018
Expires: May 29, 2019 Expires: July 1, 2019
A Session Initiation Protocol (SIP) Response Code for Rejected Calls A Session Initiation Protocol (SIP) Response Code for Rejected Calls
draft-ietf-sipcore-rejected-01 draft-ietf-sipcore-rejected-02
Abstract Abstract
This document defines the 608 (Rejected) SIP response code. This This document defines the 608 (Rejected) SIP response code. This
response code enables calling parties to learn their call was response code enables calling parties to learn an intermediary
rejected by an intermediary and will not be answered. As a 6xx code, rejected their call attempt. The call will not be answered. As a
the caller will be aware that future attempts to contact the same UAS 6xx code, the caller will be aware that future attempts to contact
will be likely to fail. The present use case driving the need for the same UAS will likely fail. The present use case driving the need
the 608 response code is when the intermediary is an analytics for the 608 response code is when the intermediary is an analytics
engine. In this case, the rejection is by a machine or other engine. In this case, the rejection is by a machine or other
process. This contrasts with the 607 (Unwanted) SIP response code, process. This contrasts with the 607 (Unwanted) SIP response code,
which a human at the target UAS indicated the call was not wanted. which a human at the target UAS indicated the call was not wanted.
In some jurisdictions this distinction is important. This document In some jurisdictions this distinction is important. This document
defines the use of the Call-Info header in 608 responses to enable defines the use of the Call-Info header in 608 responses to enable
rejected callers to contact entities that blocked their calls in rejected callers to contact entities that blocked their calls in
error. error.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 29, 2019. This Internet-Draft will expire on July 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 7 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 7
3.2. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 8 3.2. jCard Construction . . . . . . . . . . . . . . . . . . . 8
3.3. Legacy Interoperation . . . . . . . . . . . . . . . . . . 8 3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 8
3.4. Announcement Requirements . . . . . . . . . . . . . . . . 9 3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 8
3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 9
3.5. Announcement Requirements . . . . . . . . . . . . . . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 10
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 15 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 14
5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 15 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The IETF has been addressing numerous issues surrounding how to The IETF has been addressing numerous issues surrounding how to
handle unwanted and, depending on the jurisdiction, illegal calls handle unwanted and, depending on the jurisdiction, illegal calls
[RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN]
address cryptographic signing and attestation, respectively, of address cryptographic signing and attestation, respectively, of
signaling to ensure the integrity and authenticity of the asserted signaling to ensure the integrity and authenticity of the asserted
identity. identity.
skipping to change at page 3, line 12 skipping to change at page 3, line 22
caller may call a user who finds the call to be unwanted. However, caller may call a user who finds the call to be unwanted. However,
instead of marking the call as unwanted, the user may mark the call instead of marking the call as unwanted, the user may mark the call
as illegal. With that information, an analytics engine may determine as illegal. With that information, an analytics engine may determine
that all calls from that source should be blocked. However, in some that all calls from that source should be blocked. However, in some
jurisdictions blocking calls from that source for other users may not jurisdictions blocking calls from that source for other users may not
be legal. Likewise, one can envision jurisdictions that allow an be legal. Likewise, one can envision jurisdictions that allow an
operator to block such calls, but only if there is a remediation operator to block such calls, but only if there is a remediation
mechanism in place to address false positives. mechanism in place to address false positives.
Some call blocking services may return responses such as 604 (Does Some call blocking services may return responses such as 604 (Does
Not Exist Anywhere). This might be a strategy to attempt to get a Not Exist Anywhere). This might be a strategy to try to get a
destination's address removed from a calling database. However, destination's address removed from a calling database. However,
other network elements might interpret this to mean the user truly other network elements might also interpret this to mean the user
does not exist and result in the user not being able to receive calls truly does not exist and might result in the user not being able to
from anyone, even if wanted. As well, in many jurisdictions, receive calls from anyone, even if wanted. As well, in many
providing false signaling is illegal. jurisdictions, providing false signaling is illegal.
The 608 response code addresses this need of remediating falsely The 608 response code addresses this need of remediating falsely
blocked calls. Specifically, this code informs the UAC an blocked calls. Specifically, this code informs the UAC an
intermediary blocked the call and, to satisfy jurisdictional intermediary blocked the call and provide a redress mechanism,
requirements for providing a redress mechanism, how to contact the specifically how to contact the operator of the intermediary.
operator of the intermediary.
In the call handling ecosystem, users can explicitly reject a call or In the call handling ecosystem, users can explicitly reject a call or
later mark a call as being unwanted by issuing a 607 SIP response later mark a call as being unwanted by issuing a 607 SIP response
code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the operation code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the operation
of the 607 SIP response code. The UAS indicates the call was of the 607 SIP response code. The UAS indicates the call was
unwanted. As RFC8197 explains, not only does the called party desire unwanted. As RFC8197 explains, not only does the called party desire
to reject that call, they may wish to let their proxy know they might to reject that call, they can let their proxy know they consider
consider future calls from that source unwanted by responding to the future calls from that source unwanted. Upon receipt of the 607
request with the 607 response. Upon receipt of the 607 response from response from the UAS, the proxy may send call information to a call
the UAS, the proxy may send call information to a call analytics analytics engine. For various reasons described in RFC8197, if a
engine. For various reasons described in RFC8197, if a network network operator receives multiple reports of unwanted calls, that
operator receives multiple reports of unwanted calls, that may may indicate the entity placing the calls is likely to be a source of
indicate the entity placing the calls is likely to be a source of
unwanted calls for many people. As such, other users of the service unwanted calls for many people. As such, other users of the service
provider's service may wish the service provider to automatically provider's service may wish the service provider to automatically
reject calls on their behalf based on that and other analytics. reject calls on their behalf based on that and other analytics.
Another value of the 607 rejection is presuming the proxy forwards Another value of the 607 rejection is presuming the proxy forwards
the response code to the UAC, the calling UAC or intervening proxies the response code to the UAC, the calling UAC or intervening proxies
will also learn the user is not interested in receiving calls from will also learn the user is not interested in receiving calls from
that sender. that sender.
+-----------+ +-----------+
skipping to change at page 4, line 22 skipping to change at page 4, line 22
+-----------+ +-----------+
+-----+ 607 | Called | 607 +-----+ +-----+ 607 | Called | 607 +-----+
| UAC | <--------- | Party | <-------- | UAS | | UAC | <--------- | Party | <-------- | UAS |
+-----+ | Proxy | +-----+ +-----+ | Proxy | +-----+
+-----------+ +-----------+
Figure 1: Unwanted (607) Call Flow Figure 1: Unwanted (607) Call Flow
For calls rejected with a 607 from a legitimate caller, receiving a For calls rejected with a 607 from a legitimate caller, receiving a
607 response code can inform the caller to stop attempting to call 607 response code can inform the caller to stop attempting to call
the user. Moreover, if the legitimate caller believes the user is the user. Moreover, if a legitimate caller believes the user is
rejecting their calls in error, they can use other channels to rejecting their calls in error, they can use other channels to
contact the user. For example, if a pharmacy calls a user to let contact the user. For example, if a pharmacy calls a user to let
them know their prescription is available for pickup and the user them know their prescription is available for pickup and the user
mistakenly thinks the call is unwanted and issues a 607 response mistakenly thinks the call is unwanted and issues a 607 response
code, the pharmacy, having an existing relationship with the code, the pharmacy, having an existing relationship with the
customer, can send the user an email, also noting the customer might customer, can send the user an email or push a note to the pharmacist
consider not rejecting their calls in the future. to ask the customer to consider not rejecting their calls in the
future.
Moreover, many systems that allow the user to mark the call unwanted Moreover, many systems that allow the user to mark the call unwanted
(e.g., with the 607 response code) also allow the user to change (e.g., with the 607 response code) also allow the user to change
their mind and unmark such calls. This is relatively easy to their mind and unmark such calls. This is relatively easy to
implement as the user usually has a direct relationship with the implement as the user usually has a direct relationship with the
provider of the blocking service. provider of the blocking service.
However, things get more complicated if an intermediary, such as a
third-party provider of call management services that classify calls
based on the relative likelihood the call is unwanted, misidentifies
the call as unwanted. Figure 3 shows this case. Note the UAS
typically does not receive an INVITE as the proxy rejects the call on
behalf of the user. In this situation, it would be beneficial for
the caller to be able to learn who rejected the call, so they might
be able to correct the misidentification.
+--------+ +-----------+ +--------+ +-----------+
| Called | | Call | | Called | | Call |
+-----+ | Party | | Analytics | +-----+ +-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS | | UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+ +-----+ +--------+ +-----------+ +-----+
| INVITE | | | | INVITE | | |
| --------------> | INVITE | | | --------------> | INVITE | |
| | ------------------------------> | | | ------------------------------> |
| | | | | | | |
| | | 607 | | | | 607 |
| | <------------------------------ | | | <------------------------------ |
| | | | | | | |
| | Unwanted call | | | | Unwanted call | |
| 607 | -----------------> | | | 607 | -----------------> | |
| <-------------- | indicator | | | <-------------- | indicator | |
| | | | | | | |
Figure 2: Unwanted (607) Ladder Diagram Figure 2: Unwanted (607) Ladder Diagram
However, things get more complicated if an intermediary, such as a
third-party provider of call management services that classify calls
based on the relative likelihood the call is unwanted, misidentifies
the call as unwanted. Figure 3 shows this case. Note the UAS
typically does not receive an INVITE as the proxy rejects the call on
behalf of the user. In this situation, it would be beneficial for
the caller to be able to learn who rejected the call, so they might
be able to correct the misidentification.
In this situation, one might be tempted to have the intermediary use
the 607 response code. 607 indicates to the caller the subscriber did
not get the call and they do not want the call. However, RFC8197
specifies that one of the uses of 607 is to inform analytics engines
that a user (human) has rejected a call. The problem here is network
elements downstream from the intermediary might interpret the 607 as
a user (human) marking the call as unwanted, as opposed to a
statistical, machine learning, vulnerable to the base rate fallacy
[BaseRate] algorithm rejecting the call. In other words, those
downstream entities should not be relying on another entity
'deciding' the call is unwanted. By distinguishing between a (human)
user rejection and an intermediary's statistical rejection, a
downstream network element that sees a 607 response code can weight
it as a human rejection in its call analytics.
+-----------+ +-----------+
| Call | | Call |
| Analytics | | Analytics |
| Engine | | Engine |
+-----------+ +-----------+
^ | (likely not SIP) ^ | (likely not SIP)
| v | v
+-----------+ +-----------+
+-----+ 608 | Called | +-----+ +-----+ 608 | Called | +-----+
| UAC | <--------- | Party | | UAS | | UAC | <--------- | Party | | UAS |
+-----+ | Proxy | +-----+ +-----+ | Proxy | +-----+
+-----------+ +-----------+
Figure 3: Rejected (608) Call Flow Figure 3: Rejected (608) Call Flow
In this situation, one might be tempted to have the intermediary use
the 607 response code. 607 indicates to the caller the subscriber
does not want the call. However, RFC8197 specifies that one of the
uses of 607 is to inform analytics engines that a user (human) has
rejected a call. The problem here is network elements downstream
from the intermediary might interpret the 607 as a user (human)
marking the call as unwanted, as opposed to a statistical, machine
learning, vulnerable to the base rate fallacy [BaseRate] algorithm
rejecting the call. In other words, those downstream entities should
not be relying on another entity 'deciding' the call is unwanted. By
distinguishing between a (human) user rejection and an intermediary's
statistical rejection, a downstream network element that sees a 607
response code can weight it as a human rejection in its call
analytics.
It is useful for blocked callers to have a redress mechanism. One It is useful for blocked callers to have a redress mechanism. One
can imagine that some jurisdictions will require it. However, we can imagine that some jurisdictions will require it. However, we
must be mindful that most of the calls that will be blocked will, in must be mindful that most of the calls that will be blocked will, in
fact, be illegal and eligible for blocking. Thus, providing fact, be illegal and eligible for blocking. Thus, providing
alternate contact information for a user would be counterproductive alternate contact information for a user would be counterproductive
to protecting that user from illegal communications. This is another to protecting that user from illegal communications. This is another
reason we do not propose to simply allow alternate contact reason we do not propose to simply allow alternate contact
information in a 607 response message. information in a 607 response message.
One might ask why we cannot use the same mechanism an analytics One might ask why we cannot use the same mechanism an analytics
skipping to change at page 7, line 12 skipping to change at page 6, line 46
an object, namely JWS [RFC7515]. The SIP community is familiar with an object, namely JWS [RFC7515]. The SIP community is familiar with
this concept as it is the mechanism used by STIR [RFC8224]. this concept as it is the mechanism used by STIR [RFC8224].
2. Terminology 2. Terminology
This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only
when, they appear in all capitals, as shown here. when, they appear in all capitals, as shown here.
As a matter of principle, this document uses the term "UNLESS" to
distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD"
means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a.
Burger's Law of Protocol Meaningness.
3. Protocol Operation 3. Protocol Operation
For clarity, this section uses the term 'intermediary' as the entity For clarity, this section uses the term 'intermediary' as the entity
that acts as a SIP User Agent Server (UAS) on behalf of the user in that acts as a SIP User Agent Server (UAS) on behalf of the user in
the network, as opposed to the user's UAS (colloquially, but not the network, as opposed to the user's UAS (colloquially, but not
necessarily, their phone). The intermediary could be a back-to-back necessarily, their phone). The intermediary could be a back-to-back
user agent (B2BUA) or a SIP Proxy. user agent (B2BUA) or a SIP Proxy.
Figure 4 shows an overview of the call flow for a rejected call. Figure 4 shows an overview of the call flow for a rejected call.
skipping to change at page 7, line 47 skipping to change at page 7, line 40
3.1. Intermediary Operation 3.1. Intermediary Operation
An intermediary MAY issue the 608 response code in a failure response An intermediary MAY issue the 608 response code in a failure response
for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP
[RFC3261] request to indicate that an intermediary rejected the [RFC3261] request to indicate that an intermediary rejected the
offered communication as unwanted by the user. An intermediary MAY offered communication as unwanted by the user. An intermediary MAY
issue the 608 as the value of the "cause" parameter of a SIP reason- issue the 608 as the value of the "cause" parameter of a SIP reason-
value in a Reason header field [RFC3326]. value in a Reason header field [RFC3326].
Unless there are indicators the calling party will use the contents If an intermediary issues a 608 code, the intermediary SHOULD include
of the Call-Info header for malicious purposes (see Section 6), if an a Call-Info header in the response, UNLESS there are indicators the
intermediary issues a 608 code, the intermediary MUST include a Call- calling party will use the contents of the Call-Info header for
Info header in the response. malicious purposes (see Section 6).
If there is a Call-Info header, it MUST have the 'purpose' parameter If there is a Call-Info header, it MUST have the 'purpose' parameter
of 'card'. The value of the Call-Info header MUST refer to a valid of 'jwscard'. The value of the Call-Info header MUST refer to a
JWS [RFC7515] encoding of a jCard [RFC7095] object. As for the valid JWS [RFC7515] encoding of a jCard [RFC7095] object.
signature algorithms allowed and policies surrounding the issuance
and publication of public and private keys, one could expect to see
policies such as defined by SHAKEN [SHAKEN]. However, the
specification for the signature algorithm and policies for the
asserted keys are beyond the scope of this document.
The jCard referenced in the Call-Info header MUST include at least
one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this
specification MUST be prepared to receive a full jCard. Call
originators (at the UAC) can use the information returned by the
jCard to contact the intermediary that rejected the call to appeal
the intermediary's blocking of the call attempt. What the
intermediary does if the blocked caller contacts the intermediary is
outside the scope of this document.
Proxies need to be mindful that a downstream intermediary may reject Proxies need to be mindful that a downstream intermediary may reject
the attempt with a 608 while other paths may still be in progress. the attempt with a 608 while other paths may still be in progress.
In this situation, the requirements stated in Section 16.7 of RFC3261 In this situation, the requirements stated in Section 16.7 of RFC3261
[RFC3261] apply. Specifically, the proxy should cancel pending [RFC3261] apply. Specifically, the proxy should cancel pending
transactions and must not create any new branches. Note this is not transactions and must not create any new branches. Note this is not
a new requirement but simply pointing out the existing 6xx protocol a new requirement but simply pointing out the existing 6xx protocol
mechanism in SIP. mechanism in SIP.
3.2. UAC Operation 3.2. jCard Construction
The intermediary constructs the JWS as follows.
3.2.1. JOSE Header
The JOSE header MUST include the typ, alg, and x5u parameters from
JWS [RFC7515]. The typ parameter MUST have the value "vcard+json".
Implementations MUST support ES256 as JWA [RFC7518] defines it, and
MAY support other registered signature algorithms. Finally, the x5u
parameter MUST be a URI that resolves to the public key certificate
corresponding to the key used to digitally sign the JWS.
3.2.2. JWT Payload
The payload contains two JSON values. The first JWT claim that MUST
be present is the iat (issued at) claim [RFC7519]. The "iat" MUST be
set to the date and time of the issuance of the 608 response. This
mandatory component protects the response from replay attacks.
The second JWT claim that MUST be present is the jcard claim.
Section 5.3 describes the registration. In the construction of the
jcard claim, the "jcard" MUST include at least one of the URL, EMAIL,
TEL, or ADR properties. UACs supporting this specification MUST be
prepared to receive a full jCard. Call originators (at the UAC) can
use the information returned by the jCard to contact the intermediary
that rejected the call to appeal the intermediary's blocking of the
call attempt. What the intermediary does if the blocked caller
contacts the intermediary is outside the scope of this document.
3.2.3. JWS Signature
JWS [RFC7515] specifies the procedure for calculating the signature
over the jCard JWT. Section 4 of this document has a detailed
example on constructing the JWS, including the signature.
3.3. UAC Operation
A UAC conforming to this specification MUST include the sip.608 A UAC conforming to this specification MUST include the sip.608
feature capability tag in the INVITE request. feature capability tag in the INVITE request.
Upon receiving a 608 response, UACs perform normal SIP processing for Upon receiving a 608 response, UACs perform normal SIP processing for
6xx responses. 6xx responses.
3.3. Legacy Interoperation 3.4. Legacy Interoperation
If the UAC indicates support for 608 and the intermediary issues a If the UAC indicates support for 608 and the intermediary issues a
608, life is good as the UAC will receive all the information it 608, life is good as the UAC will receive all the information it
needs to remediate an erroneous block by an intermediary. However, needs to remediate an erroneous block by an intermediary. However,
what if the UAC does not understand 608? Besides a UAC predating what if the UAC does not understand 608? For example, how can we
this specification, the could occur for callers from the legacy, non- support callers from a legacy, non-SIP public switched network
SIP public switched network connecting to the SIP network via a media connecting to the SIP network via a media gateway?
gateway.
We address this situation by having the first network element that We address this situation by having the first network element that
conforms with this specification play an announcement in the media. conforms with this specification play an announcement in the media.
See Section 3.4 for requirements on the announcement. The simple See Section 3.5 for requirements on the announcement. The simple
rule is a network element that inserts the sip.608 feature capability rule is a network element that inserts the sip.608 feature capability
MUST be able to convey at a minimum whom to contact, ideally how to MUST be able to convey at a minimum how to contact the operator of
contact, the operator of the intermediary that rejected the call the intermediary that rejected the call attempt.
attempt.
The degenerate case is the intermediary is the only element that The degenerate case is the intermediary is the only element that
understands the semantics of the 608 response code. Obviously, any understands the semantics of the 608 response code. Obviously, any
SIP device will understand that a 608 response code is a 6xx error. SIP device will understand that a 608 response code is a 6xx error.
However, there are no other elements in the call path that understand However, there are no other elements in the call path that understand
the meaning of the value of the Call-Info header. The intermediary the meaning of the value of the Call-Info header. The intermediary
knows this is the case as the INVITE request will not have the knows this is the case as the INVITE request will not have the
sip.608 feature capability. In this case, one can consider the sip.608 feature capability. In this case, one can consider the
intermediary to be the element 'inserting' a virtual sip.608 feature intermediary to be the element 'inserting' a virtual sip.608 feature
capability. As such, the intermediary MUST play the announcement, capability. As such, the intermediary SHOULD play the announcement,
with the caveats described in Section 3.4 and Section 6. UNLESS the caveats described in Section 3.5 and Section 6 hold.
Now we take the case where a network element that understands the 608 Now we take the case where a network element that understands the 608
response code receives an INVITE for further processing. A network response code receives an INVITE for further processing. A network
element conforming with this specification MUST insert the sip.608 element conforming with this specification MUST insert the sip.608
feature capability, per the behaviors described in Section 4.2 of feature capability, per the behaviors described in Section 4.2 of
[RFC6809]. This information will be in the JWS of the jCard [RFC6809].
referenced by the Call-Info header in the 608 response message. Note
this specification does not specify the mechanism for such
notification to the UAC (see Section 3.4).
Do note that even if a network element plays an announcement Do note that even if a network element plays an announcement
describing the contents of the 608 response message, the network describing the contents of the 608 response message, the network
element MUST also send the 608 response code message as the final element MUST forward the 608 response code message as the final
response to the INVITE. response to the INVITE.
One aspect of using a feature capability is only the network elements One aspect of using a feature capability is only the network elements
that will consume (UAC) or play an announcement (media gateway, SBC, that will consume (UAC) or play an announcement (media gateway, SBC,
or proxy) need understand the sip.608 feature capability. All other or proxy) need understand the sip.608 feature capability. All other
(existing) infrastructure can remain without modification, assuming (existing) infrastructure can remain without modification, assuming
they are conformant to Section 16.6 of [RFC3261], specifically they they are conformant to Section 16.6 of [RFC3261], specifically they
will pass headers such as "Feature-Capability: sip.608" unmodified. will pass headers such as "Feature-Capability: sip.608" unmodified.
3.4. Announcement Requirements 3.5. Announcement Requirements
There are a few requirements on the element that will be doing the There are a few requirements on the element that will be doing the
announcement for legacy interoperation. announcement for legacy interoperation.
As noted above, the element that inserts the sip.608 feature As noted above, the element that inserts the sip.608 feature
capability is responsible for conveying the information referenced by capability is responsible for conveying the information referenced by
the Call-Info header in the 608 response message. However, this the Call-Info header in the 608 response message. However, this
specification does not mandate the modality for conveying that specification does not mandate the modality for conveying that
information. information.
Let us take the case where a telecommunications service provider Let us take the case where a telecommunications service provider
controls the element inserting the sip.608 feature capability. It controls the element inserting the sip.608 feature capability. It
would be reasonable to expect the service provider would play an would be reasonable to expect the service provider would play an
actual announcement in the media path towards the UAC (caller). It announcement in the media path towards the UAC (caller). It is
is important to note the network element should be mindful of the important to note the network element should be mindful of the media
media type requested by the UAC as it formulates the announcement. type requested by the UAC as it formulates the announcement. For
For example, it would make sense for an INVITE that only indicated example, it would make sense for an INVITE that only indicated audio
audio codecs in the SDP [RFC4566] to result in an audio announcement. codecs in the SDP [RFC4566] to result in an audio announcement.
However, if the INVITE only indicated a real-time text codec, for However, if the INVITE only indicated a real-time text codec, the
example, the network element SHOULD send the information in a text network element SHOULD send the information in a text format, not an
format, not an audio format, unless the network element is unable to audio format, unless the network element is unable to render the
render the information in the requested media format. information in the requested media format.
It is also possible for the network element inserting the sip.608 It is also possible for the network element inserting the sip.608
feature capability to be under the control of the same entity that feature capability to be under the control of the same entity that
controls the UAC. For example, a large call center might have legacy controls the UAC. For example, a large call center might have legacy
UACs, but have a modern outbound calling proxy that understands the UACs, but have a modern outbound calling proxy that understands the
full semantics of the 608 response code. In this case, it is enough full semantics of the 608 response code. In this case, it is enough
for the outbound calling proxy to digest the Call-Info information for the outbound calling proxy to digest the Call-Info information
and handle the information digitally, rather than 'transcoding' the and handle the information digitally, rather than 'transcoding' the
Call-Info information for presentation to the caller. Call-Info information for presentation to the caller.
4. Examples 4. Examples
These examples are not normative, for clarity do not include all These examples are not normative, do not include all protocol
protocol elements, and may have errors. Review the protocol elements, and may have errors. Review the protocol documents for
documents for actual syntax and semantics of the protocol elements. actual syntax and semantics of the protocol elements.
4.1. Full Exchange
Given an INVITE (shamelessly taken from [SHAKEN]): Given an INVITE (shamelessly taken from [SHAKEN]):
INVITE sip:+12155551213@tel.example1.net SIP/2.0 INVITE sip:+12155551213@tel.example1.net SIP/2.0
Max-Forwards: 69 Max-Forwards: 69
Contact: <sip:+12155551212@69.241.19.12:50207;rinstance=9da3088f36cc> Contact: <sip:+12155551212@69.241.19.12:50207;rinstance=9da3088f36cc>
To: <sip:+12155551213@tel.example1.net> To: <sip:+12155551213@tel.example1.net>
From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40 From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155551212@tel.example2.net>, P-Asserted-Identity: "Alice"<sip:+12155551212@tel.example2.net>,
skipping to change at page 11, line 44 skipping to change at page 11, line 44
a=sendrecv a=sendrecv
An intermediary could reply: An intermediary could reply:
SIP/2.0 608 Rejected SIP/2.0 608 Rejected
Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1 Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40 From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40
To: <sip:+12155551213@tel.example1.net> To: <sip:+12155551213@tel.example1.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE CSeq: 2 INVITE
Call-Info: <https://blocker.example.net/complaints.json>;purpose=card Call-Info: <https://block.example.net/complaint.json>;purpose=jwscard
A minimal jCard could be: The location https://block.example.net/complaint.json resolves to a
JWS. The JWS would be constructed as follows.
The JWS header of this example jCard could be:
{ {"alg":"ES256"},
{"typ":"vcard+json"},
{"x5u":"https://certs.example.net/reject_key.cer"} }
Now, let us construct a minimal jCard. For this example, the jCard
refers the caller to an email address, bitbucket@blocker.example.net:
["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"}, ["email", {"type":"work"},
"text", "bitbucket@blocker.example.net"] "text", "bitbucket@blocker.example.net"]
] ]
] ]
In base64: With this jCard, we can now construct the JWT:
WyJ2Y2FyZCIsCiAgWwogICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJd {
LAogICAgWyJmbiIsIHt9LCAidGV4dCIsICJSb2JvY2FsbCBBZGp1ZGljYXRpb24i "iat":1546008698,
XSwKICAgIFsiZW1haWwiLCB7InR5cGUiOiJ3b3JrIn0sICJ0ZXh0IiwgImJpdGJ1 "jcard":["vcard",
Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICBdCl0K [
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"},
"text", "bitbucket@blocker.example.net"]
]
]
}
The JWS header of this example jCard could be: In order to calculate the signature, we need to encode the JOSE
header and JWT into base64. As an implementation note, one can trim
whitespace in the JSON objects to save a few bytes. UACs MUST be
prepared to receive pretty printed, compact, or bizarrely formatted
JSON. For the purposes of this example, we leave the objects with
pretty whitespace. Speaking of pretty vs. machine formatting, these
examples have line breaks in the base64 encodings for ease of
publication in the RFC format. The specification of base64 allows
for these line breaks and the decoded text works just fine. However,
those extra line break octets would affect the calculation of the
signature. As such, implementations MUST NOT insert line breaks into
the base64 encodings of the JOSE header or JWT. This also means UACs
MUST be prepared to receive arbitrarily long octet streams from the
URI referenced by the Call-Info SIP header.
{ {"alg":"ES256"}, base64 of JOSE header:
{"typ":"vcard+json"}, eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
{"x5u":"https://certs.example.net/reject_key.cer"} } NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo=
In base64: base64 of JWT:
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
In this case, the object to be signed (remembering this is just a
single, long line; the line breaks are for ease of review but do not
appear in the actual text being signed is as follows:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo= fQo=
.
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
The resulting JWS, presuming the base64 encoding of the ECDSA P-256 We use the following X.509 PKCS #8-encoded ECDSA private key, also
SHA-256 digital signature using the certificate mentioned above is, shamelessly taken from [SHAKEN]), as an example key for signing the
the final string after the period in the example below, stored at hash of the above text. Do NOT use this key in real life! It is for
https://blocker.example.net/complaints.json, the file could thus exemplary purposes only. At the very least, we would strongly
contain: recommend the key being encrypted at rest.
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----
The resulting JWS, using the above key on the above object, renders
the following ECDSA P-256 SHA-256 digital signature.
MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5ehMOwjM
TS+skjf1163ihH5+yIHQS3quklEt/9o=
Thus, the JWS stored at https://blocker.example.net/complaints.json,
would contain:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo=.WyJ2Y2FyZCIsCiAgWwogICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQ fQo=.ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICA
uMCJdLAogICAgWyJmbiIsIHt9LCAidGV4dCIsICJSb2JvY2FsbCBBZGp1ZGljYXR gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB
pb24iXSwKICAgIFsiZW1haWwiLCB7InR5cGUiOiJ3b3JrIn0sICJ0ZXh0IiwgImJ bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA
pdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICBdCl0K.OSaG/DGW8jxfWM gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ
Z+cExnmhCPEXxIg+dEiJakRKD/E4KZak8PsEv/5Bh0bz9KMv8d+o6JnT76v9cuk+ 0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB
d3CxE3HW dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e
hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o=
4.2. Web Site jCard
For an intermediary that provides a Web site for adjudication, the For an intermediary that provides a Web site for adjudication, the
jCard could contain the following. Note the calculation of the JWS jCard could contain the following. Note the calculation of the JWS
is not shown; the URI reference in the Call-Info header would be to is not shown; the URI reference in the Call-Info header would be to
the JWS of the signed jCard. the JWS of the signed jCard.
["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["url", {"type":"work"}, ["url", {"type":"work"},
"text", "https://blocker.example.net/adjudication-form"] "text", "https://blocker.example.net/adjudication-form"]
] ]
] ]
4.3. Multi-modal jCard
For an intermediary that provides a telephone number and a postal For an intermediary that provides a telephone number and a postal
address, the jCard could contain the following. Note the calculation address, the jCard could contain the following. Note the calculation
of the JWS is not shown; the URI reference in the Call-Info header of the JWS is not shown; the URI reference in the Call-Info header
would be to the JWS of the signed jCard. would be to the JWS of the signed jCard.
["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["adr", {"type":"work"}, "text", ["adr", {"type":"work"}, "text",
skipping to change at page 13, line 32 skipping to change at page 15, line 4
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["adr", {"type":"work"}, "text", ["adr", {"type":"work"}, "text",
["Argument Clinic", ["Argument Clinic",
"12 Main St","Anytown","AP","000000","Somecountry"] "12 Main St","Anytown","AP","000000","Somecountry"]
] ]
["tel", {"type":"work"}, "uri", "tel:+1-555-555-1212"] ["tel", {"type":"work"}, "uri", "tel:+1-555-555-1212"]
] ]
] ]
Note that it is up to the UAC to decide which jCard contact modality, Note that it is up to the UAC to decide which jCard contact modality,
if any, it will use. if any, it will use.
4.4. Legacy Interoperability
Figure 5 depicts a call flow illustrating legacy interoperability. Figure 5 depicts a call flow illustrating legacy interoperability.
In this non-normative example, we see a UAC that does not support the In this non-normative example, we see a UAC that does not support the
full semantics for 608. However, there is an SBC that does support full semantics for 608. However, there is an SBC that does support
608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the 608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the
Feature-Caps header for the INVITE. When the intermediary, labeled Feature-Caps header for the INVITE. When the intermediary, labeled
"Called Party Proxy" in the figure, rejects the call, it knows it can "Called Party Proxy" in the figure, rejects the call, it knows it can
simply perform the processing described in this document. Since the simply perform the processing described in this document. Since the
intermediary saw the sip.608 feature capability, it knows it does not intermediary saw the sip.608 feature capability, it knows it does not
need to send any media describing whom to contact in the event of an need to send any media describing whom to contact in the event of an
erroneous rejection. erroneous rejection.
skipping to change at page 15, line 9 skipping to change at page 16, line 28
them on", followed by a text-to-speech translation of the telephone them on", followed by a text-to-speech translation of the telephone
number in the TEL field. number in the TEL field.
Note the SBC also still sends the full 608 response code, including Note the SBC also still sends the full 608 response code, including
the Call-Info header, towards the UAC. the Call-Info header, towards the UAC.
5. IANA Considerations 5. IANA Considerations
5.1. SIP Response Code 5.1. SIP Response Code
This document defines a new SIP response code, 608. Please register This document defines a new SIP response code, 608 in the "Response
the response code in the "Response Codes" subregistry of the "Session Codes" subregistry of the "Session Initiation Protocol (SIP)
Initiation Protocol (SIP) Parameters" registry at Parameters" registry defined in [RFC3261].
<http://www.iana.org/assignments/sip-parameters>.
Response code: 608 Response code: 608
Description: Rejected Description: Rejected
Reference: [RFCXXXX] Reference: [RFCXXXX]
5.2. SIP Feature-Capability Indicator 5.2. SIP Feature-Capability Indicator
This document defines the feature capability sip.608 in the "SIP This document defines the feature capability sip.608 in the "SIP
Feature-Capability Indicator Registration Tree" registry defined in Feature-Capability Indicator Registration Tree" registry defined in
[RFC6809]. [RFC6809].
Name: sip.608 Name: sip.608
Description: This feature capability indicator, when included in a Description: This feature capability indicator, when included in a
Feature-Caps header field of an INVITE request, indicates that the Feature-Caps header field of an INVITE request, indicates that the
entity that inserted the sip.608 Feature-Caps value will be entity that inserted the sip.608 Feature-Caps value will be
responsible for indicating to the caller any information contained in responsible for indicating to the caller any information contained
the 608 SIP response code, specifically the value referenced by the in the 608 SIP response code, specifically the value referenced by
Call-Info header. the Call-Info header
Reference: [RFCXXXX] Reference: [RFCXXXX]
5.3. JSON Web Token Claim
This document defines the new JSON Web Token claim in the "JSON Web
Token Claims" sub-registry created by [RFC7519]. Section 3.2.2
defines the syntax. The required information is:
Claim Name: jcard
Claim Description: jCard data
Change Controller: IESG
Reference: [RFCXXXX], [RFC7095]
5.4. Call-Info Purpose
This document defines the new predefined value "jwscard" for the
"purpose" header field parameter of the Call-Info header field. This
modifies the registry header field parameters and parameter values by
adding this RFC as a reference to the line for the header field
"Call-Info" and parameter name "purpose":
Header Field: Call-Info
Parameter Name: purpose
Predefined Values: Yes
Reference: [RFCXXXX]
6. Security Considerations 6. Security Considerations
Intermediary operators need to be mindful of whom they are sending Intermediary operators need to be mindful of whom they are sending
the 608 response to. There is a risk that a truly malicious caller the 608 response to. There is a risk that a truly malicious caller
is being rejected. This raises two issues. The first is the caller, is being rejected. This raises two issues. The first is the caller,
being alerted their call is being automatically rejected, may change being alerted their call is being automatically rejected, may change
their call behavior to defeat call blocking systems. The second, and their call behavior to defeat call blocking systems. The second, and
more significant risk, is that by providing a contact in the Call- more significant risk, is that by providing a contact in the Call-
Info field, the intermediary may be giving the malicious caller a Info field, the intermediary may be giving the malicious caller a
skipping to change at page 17, line 39 skipping to change at page 19, line 39
<https://www.rfc-editor.org/info/rfc6809>. <https://www.rfc-editor.org/info/rfc6809>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014, DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>. <https://www.rfc-editor.org/info/rfc7095>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[BaseRate] [BaseRate]
Bar-Hillel, M., "The Base-Rate Fallacy in Probability Bar-Hillel, M., "The Base-Rate Fallacy in Probability
Judgements", 4 1977, Judgements", 4 1977,
<http://www.dtic.mil/get-tr-doc/pdf?AD=ADA045772>. <http://www.dtic.mil/get-tr-doc/pdf?AD=ADA045772>.
 End of changes. 52 change blocks. 
153 lines changed or deleted 290 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/