draft-ietf-sipcore-status-unwanted-01.txt		draft-ietf-sipcore-status-unwanted-02.txt
	SIPCORE H. Schulzrinne		SIPCORE H. Schulzrinne
	Internet-Draft FCC		Internet-Draft FCC
	Intended status: Standards Track January 4, 2017		Intended status: Standards Track January 12, 2017
	Expires: July 8, 2017		Expires: July 16, 2017
	A SIP Response Code for Unwanted Calls		A SIP Response Code for Unwanted Calls
	draft-ietf-sipcore-status-unwanted-01		draft-ietf-sipcore-status-unwanted-02
	Abstract		Abstract
	This document defines the 666 (Unwanted) SIP response code, allowing		This document defines the 666 (Unwanted) SIP response code, allowing
	called parties to indicate that the call was unwanted. SIP entities		called parties to indicate that the call or message was unwanted.
	may use this information to adjust how future calls from this calling		SIP entities may use this information to adjust how future calls from
	party are handled for the called party or more broadly.		this calling party are handled for the called party or more broadly.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 July 8, 2017.		This Internet-Draft will expire on July 16, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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. Normative Language . . . . . . . . . . . . . . . . . . . . . 2		2. Normative Language . . . . . . . . . . . . . . . . . . . . . 2
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3		4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 4		5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 4
	5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 4		5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	In many countries, an increasing number of calls are unwanted		In many countries, an increasing number of calls are unwanted
	[RFC5039]: they might be fraudulent, illegal telemarketing or the		[RFC5039]: they might be fraudulent, illegal telemarketing or the
	receiving party does not want to be disturbed by, say, surveys or		receiving party does not want to be disturbed by, say, surveys or
	solicitation by charities. Carriers and other service providers may		solicitation by charities. Carriers and other service providers may
	want to help their subscribers avoid receiving such calls, using a		want to help their subscribers avoid receiving such calls, using a
	variety of global or user-specific filtering algorithms. One input		variety of global or user-specific filtering algorithms. One input
	into such algorithms is user feedback. User feedback may be offered		into such algorithms is user feedback. User feedback may be offered
	through smartphone apps, APIs or within the context of a SIP-		through smartphone apps, APIs or within the context of a SIP-
	initiated call. This document addresses only the last mode, where		initiated call. This document addresses only the last mode, where
	the called party either rejects the SIP [RFC3261] request, typically		the called party either rejects the SIP [RFC3261] request, typically
	requests using the INVITE or MESSAGE methods, as unwanted or		requests using the INVITE or MESSAGE methods, as unwanted or
	terminates the call with a BYE request after answering the call. To		terminates the session with a BYE request after answering the call.
	allow the called party to express that the call was unwanted, this		To allow the called party to express that the call was unwanted, this
	document defines the 666 (Unwanted) response code. The called user		document defines the 666 (Unwanted) response code. The called user
	agent (UAS), based on input from the called party or some UA-internal		agent (UAS), based on input from the called party or some UA-internal
	logic, uses this to indicate that future calls from the same caller		logic, uses this to indicate that future calls from the same caller
	are also unwanted.		are also unwanted.
			As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity"
			or "calling party identity" in this document to mean either a
			canonical address-of-record (AoR) SIP URI employed to reach a user
			(such as 'sip:alice@atlanta.example.com'), or a telephone number,
			which commonly appears in either a tel URI [RFC3966] or as the user
			portion of a SIP URI.
	2. Normative Language		2. Normative Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in BCP 14, RFC 2119		document are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119].		[RFC2119].
	3. Motivation		3. Motivation
	None of the existing 4xx, 5xx or 6xx response codes signify that		None of the existing 4xx, 5xx or 6xx response codes signify that this
	calls from this caller are unwanted by the called party. The		SIP request is unwanted by the called party. The particular response
	particular response code number was chosen to reflect the distaste		code number was chosen to reflect the distaste felt by many upon
	felt by many upon receiving such calls.		receiving such calls.
	4. Behavior of SIP Entities		4. Behavior of SIP Entities
	The response code 666 MAY be used in a failure response for an		The response code 666 MAY be used in a failure response for an
	INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to		INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to
	indicate that the offered communication is unwanted. The response		indicate that the offered communication is unwanted. The response
	code MAY also be used as the value of the "cause" parameter of a SIP		code MAY also be used as the value of the "cause" parameter of a SIP
	reason-value in a Reason header field [RFC3326], typically when the		reason-value in a Reason header field [RFC3326], typically when the
	UAS issues a BYE or CANCEL request terminating an incoming call.		UAS issues a BYE request terminating an incoming call or the UAC
			issues a CANCEL request when forking a call. (Including a Reason
			header field with the 666 status code allows the UAS that receive a
			CANCEL request to make an informed choice whether and how to include
			such calls in their missed-call list.)
	The SIP entities receiving this response code are not obligated to		The SIP entities receiving this response code are not obligated to
	take any particular action. The service provider delivering calls to		take any particular action beyond those appropriate for 6xx
	the user issuing the response, for example, MAY add the calling party		responses. Following the default handling for 6xx responses in
	to a personal blacklist specific to the called party, MAY use the		[RFC5057], the 666 response destroys the transaction. The service
	information as input when computing the likelihood that the calling		provider delivering calls or messages to the user issuing the
	party is placing unwanted calls ("crowd sourcing"), MAY initiate a		response, for example, MAY add the calling party to a personal
	traceback request, and MAY report the calling number to government		blacklist specific to the called party, MAY use the information as
	authorities.		input when computing the likelihood that the calling party is placing
			unwanted calls ("crowd sourcing"), MAY initiate a traceback request,
			and MAY report the calling party identity to government authorities.
	Receiving systems could decide to treat pre-call and mid-call		Systems receiving 666 responses could decide to treat pre-call and
	responses differently, given that the called party has had access to		mid-call responses differently, given that the called party has had
	call content for mid-call rejections. In other words, depending on		access to call content for mid-call rejections. In other words,
	the implementation, the response code does not necessarily		depending on the implementation, the response code does not
	automatically block all calls from that number. The same user		necessarily automatically block all calls from that caller identity.
	interface action might also trigger addition of the number to a		The same user interface action might also trigger addition of the
	local, on-device blacklist or graylist, e.g., causing such calls to		caller identity to a local, on-device blacklist or graylist, e.g.,
	be flagged or alerted with a different ring tone.		causing such calls to be flagged or alerted with a different ring
			tone.
	The actions described here do not depend on the nature of the SIP		The actions described here do not depend on the nature of the SIP
	URI, e.g., whether it describes a telephone number or not; however,		URI, e.g., whether it describes a telephone number or not; however,
	the same anonymous SIP URI [RFC3323] may be used by multiple callers		the same anonymous SIP URI [RFC3323] may be used by multiple callers
	and thus such URIs are unlikely to be appropriate for URI-specific		and thus such URIs are unlikely to be appropriate for URI-specific
	call treatment. SIP entities tallying responses for particular		call treatment. SIP entities tallying responses for particular
	callers may need to consider canonicalzing SIP URIs, including		callers may need to consider canonicalzing SIP URIs, including
	telephone numbers, as described in [I-D.ietf-stir-rfc4474bis].		telephone numbers, as described in [I-D.ietf-stir-rfc4474bis]. The
			calling party may be identified in different locations in the SIP
			header, e.g., the From header field, P-Asserted-Identity or History-
			Info, and may also be affected by diverting services.
	We define a SIP feature-capability [RFC6809], sip.666, that allows		This document defines a SIP feature-capability [RFC6809], sip.666,
	the registrar to indicate that the corresponding proxy supports this		that allows the registrar to indicate that the corresponding proxy
	particular response code. This allows the UA, for example, to		supports this particular response code. This allows the UA, for
	provide a suitable user interface element, such as a "spam" button,		example, to provide a suitable user interface element, such as a
	only if its service provider actually supports the feature. The		"spam" button, only if its service provider actually supports the
	presence of the feature capability does not imply that the provider		feature. The presence of the feature capability does not imply that
	will take any particular action, such as blocking future calls. A UA		the provider will take any particular action, such as blocking future
	may still decide to render a "spam" button even without such as a		calls. A UA may still decide to render a "spam" button even without
	capability if, for example, it maintains a device-local blacklist or		such as a capability if, for example, it maintains a device-local
	reports unwanted calls to a third party.		blacklist or reports unwanted calls to a third party.
	5. IANA Considerations		5. IANA Considerations
	5.1. SIP Response Code		5.1. SIP Response Code
	This document registers a new SIP response code. This response code		This document registers a new SIP response code. This response code
	is defined by the following information, which is to be added to the		is defined by the following information, which is to be added to the
	"Response Codes" sub-registry under http://www.iana.org/assignments/		"Response Codes" sub-registry under http://www.iana.org/assignments/
	sip-parameters.		sip-parameters.
	skipping to change at page 4, line 36 ¶		skipping to change at page 5, line 7 ¶
	Name sip.666		Name sip.666
	Description This feature-capability indicator when used in a		Description This feature-capability indicator when used in a
	REGISTER response indicates that the server will process the 666		REGISTER response indicates that the server will process the 666
	response code. This does not imply any specific action.		response code. This does not imply any specific action.
	Reference [this RFC]		Reference [this RFC]
	6. Security Considerations		6. Security Considerations
	If the calling party number is spoofed, users may report the number		If the calling party address is spoofed, users may report the caller
	as placing unwanted calls, possibly leading to the blocking of calls		identity as placing unwanted calls, possibly leading to the blocking
	from the legitimate user of the number in addition to the unwanted		of calls from the legitimate user of the caller identity in addition
	caller, i.e., creating a form of denial-of-service attack. Thus, the		to the unwanted caller, i.e., creating a form of denial-of-service
	response code SHOULD NOT be used for creating global call filters		attack. Thus, the response code SHOULD NOT be used for creating
	unless the calling party number has been authenticated using		global call filters unless the calling party identity has been
	[I-D.ietf-stir-rfc4474bis] as being assigned to the caller placing		authenticated using [I-D.ietf-stir-rfc4474bis] as being assigned to
	the unwanted call. (The creation of call filters local to a user		the caller placing the unwanted call. (The creation of call filters
	agent is beyond the scope of this document.)		local to a user agent is beyond the scope of this document.)
	Even if the number is not spoofed, a call recipient might flag		Even if the identity is not spoofed, a call or message recipient
	legitimate numbers, e.g., to extract vengeance on a person or		might flag legitimate caller identities, e.g., to extract vengeance
	business, or simply by mistake. To correct errors, any additions to		on a person or business, or simply by mistake. To correct errors,
	a personal list of blocked numbers should be observable and		any additions to a personal list of blocked caller identities should
	reversible by the party being protected by the blacklist. For		be observable and reversible by the party being protected by the
	example, the list may be shown on a web page or the subscriber may be		blacklist. For example, the list may be shown on a web page or the
	notified by periodic email reminders. Any additions to a global or		subscriber may be notified by periodic email reminders. Any
	carrier-wide list of unwanted callers needs to consider that any		additions to a global or carrier-wide list of unwanted callers needs
	user-initiated mechanism will suffer from an unavoidable rate of		to consider that any user-initiated mechanism will suffer from an
	false positives and tailor their algorithms accordingly, e.g., by		unavoidable rate of false positives and tailor their algorithms
	comparing the fraction of delivered calls for a particular caller		accordingly, e.g., by comparing the fraction of delivered calls for a
	that are flagged as unwanted rather than just the absolute number,		particular caller that are flagged as unwanted rather than just the
	and considering time-weighted filters that give more credence to		absolute number, and considering time-weighted filters that give more
	recent feedback.		credence to recent feedback.
	Since telephone numbers are routinely re-assigned to new subscribers,		Since caller identities are routinely re-assigned to new subscribers,
	algorithms are advised to consider whether the number has been re-		algorithms are advised to consider whether the caller identity has
	assigned to a new subscriber and possibly reset any related rating.		been re-assigned to a new subscriber and possibly reset any related
			rating.
	For both individually-authenticated and unauthenticated calls,		For both individually-authenticated and unauthenticated calls,
	recipients may want to distinguish responses sent before and after		recipients of response code 666 may want to distinguish responses
	the call has been answered, ascertaining whether either response		sent before and after the call has been answered, ascertaining
	timing suffers from a lower false-positive rate.		whether either response timing suffers from a lower false-positive
			rate.
	7. Acknowledgements		7. Acknowledgements
	Tolga Asveren, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani,		Tolga Asveren, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani,
	Paul Kyzivat, Jean Mahoney, Brian Rosen, Chris Wendt and Dale Worley		Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Brian
	provided helpful comments.		Rosen, Brett Tate, Chris Wendt and Dale Worley provided helpful
			comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 5, line 47 ¶		skipping to change at page 6, line 25 ¶
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<http://www.rfc-editor.org/info/rfc3261>.		<http://www.rfc-editor.org/info/rfc3261>.
	[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason		[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
	Header Field for the Session Initiation Protocol (SIP)",		Header Field for the Session Initiation Protocol (SIP)",
	RFC 3326, DOI 10.17487/RFC3326, December 2002,		RFC 3326, DOI 10.17487/RFC3326, December 2002,
	<http://www.rfc-editor.org/info/rfc3326>.		<http://www.rfc-editor.org/info/rfc3326>.
			[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
			Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057,
			November 2007, <http://www.rfc-editor.org/info/rfc5057>.
	[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to		[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
	Indicate Support of Features and Capabilities in the		Indicate Support of Features and Capabilities in the
	Session Initiation Protocol (SIP)", RFC 6809,		Session Initiation Protocol (SIP)", RFC 6809,
	DOI 10.17487/RFC6809, November 2012,		DOI 10.17487/RFC6809, November 2012,
	<http://www.rfc-editor.org/info/rfc6809>.		<http://www.rfc-editor.org/info/rfc6809>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-stir-rfc4474bis]		[I-D.ietf-stir-rfc4474bis]
	Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-15		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-15
	(work in progress), October 2016.		(work in progress), October 2016.
	[RFC3323] Peterson, J., "A Privacy Mechanism for the Session		[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
	Initiation Protocol (SIP)", RFC 3323,		Initiation Protocol (SIP)", RFC 3323,
	DOI 10.17487/RFC3323, November 2002,		DOI 10.17487/RFC3323, November 2002,
	<http://www.rfc-editor.org/info/rfc3323>.		<http://www.rfc-editor.org/info/rfc3323>.
			[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
			RFC 3966, DOI 10.17487/RFC3966, December 2004,
			<http://www.rfc-editor.org/info/rfc3966>.
	[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation		[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
	Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,		Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
	January 2008, <http://www.rfc-editor.org/info/rfc5039>.		January 2008, <http://www.rfc-editor.org/info/rfc5039>.
	Author's Address		Author's Address
	Henning Schulzrinne		Henning Schulzrinne
	FCC		FCC
	445 12th Street SW		445 12th Street SW
	Washington, DC 20554		Washington, DC 20554
End of changes. 23 change blocks.
	76 lines changed or deleted		104 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/