Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard

[Pete Resnick <[e-mail]>]

I'm sorry to say that I do not think this mechanism is well thought out, 
I think it actually causes active harm to interoperability, and I think 
this document should be abandoned for a better (and simpler) solution to 
the problem, which I describe below.

I will note that I have not been following the discussion of this 
document except for it's introduction at the last plenary meeting, but I 
(and others) did give comments at that time that as far as I can tell 
were not taken into account. I did review the thread on the sipcore list 
regarding the difference between the new code and the 603 code. That 
thread does not address my concerns, and in fact in some way reinforces 
it. I have not reviewed other discussion on the list.

The purported purpose of this 666 mechanism is to allow additional 
semantics to be expressed beyond a simple 603 (Decline). That is a fine 
desire. However, instead of adding decent semantics to declining a call, 
666 adds only one additional bit of information to 603, and that one bit 
ends up causing more semantic ambiguity: The user has still declined the 
call (just as 603 would have), and has added that the call is *somehow* 
unwanted (so a provider *could* act to prevent such calls in the 
future), but the user has not indicated the *reason* they indicate the 
call is unwanted. Is it because they want to add this calling party to a 
call block list? Is it that they want to reject all calls of this 
particular class (cf. draft-ietf-sipcore-callinfo-spam)? Is there some 
other handling that would be appropriate given the particular reason the 
user has rejected the call? The best a provider is going to be able to 
do is guess. The document admits the ambiguity in the semantics, saying 
that the provider will have to use heuristics to guess at what the user 
really wants. We should not be introducing a new mechanism that only 
adds to the semantic ambiguity and might end up with results that the 
user might specifically not want in a particular case. What I think was 
really intended all along was to have un-upgraded implementations treat 
these rejections just like 603, but add some semantics that upgraded 
implementations can use to determine what ought to be done in the 
future.

The right solution, IMO, is to simply add a header to the 603 response 
that indicates what the user means by their declining, and gives a real 
indication of how handle such calls in the future. Call it 
"Decline-Type" for argument sake. Just like the Retry-After header adds 
semantics to indicate when the caller might want to try an identical 
call again, this new header will indicate that the user never wants a 
call from this particular caller again (e.g., "Decline-Type: 
block-caller", which the service provider can definitively use to add 
the caller to a block list), or that this caller and every caller with a 
similar type should be rejected (e.g. "Decline-Type: block-caller-type; 
type=political", which the provider could definitively use to reject 
similar calls in the future), etc.. With this, there's no need for a 
bunch of MAYs such that appear in section 4, you get an extensible 
mechanism that could be used by any 603 response. You also get the added 
bonus that un-upgraded entities will continue to treat this just like 
every other 603 without a Retry-After header, which is exactly what you 
want.

To be clear, the three things I am concerned about are:

1. The 666 mechanism leaves the decision of what is meant by "unwanted" 
to the provider, which will inevitably cause data loss through the use 
of heuristics. Adding a header to the 603 response is an extensible 
mechanism that could capture the single semantic bit of 666 *and any 
future semantics that one wishes to add*, without requiring the provider 
to guess. The provider gets definitive information that it can act on.

2. The 666 mechanism limits the implementation of the mechanism to a 
1-button choice and requires additional standardization work to use a 
different UI. Clearly 666 was designed around something akin to a "SPAM" 
button in the UI. But what if I want a field in my address book that 
says, "Permanently block this particular caller" (say, my ex-boyfriend 
or my annoying neighbor)? I don't want to indicate that these are spam 
calls because I don't want my provider applying heuristics to them. I 
want to send back a 603 with a header that says, "Block these whenever 
you see them, but only for me." I can think of all sorts of 
other-than-one-button UIs that someone might want to implement. 666 is 
tied to a particular UI. 603 with a header is extensible.

3. The 666 mechanism will be treated as a 600 "Busy" error by 
un-upgraded callers and/or providers. That might imply to some 
implementations that they should try to re-dial (e.g., the provider 
using the auto-redial feature) or to engage in other poor behavior. 603 
with no Retry-After header already has a semantic of "The call was 
rejected and I'm not telling you when a good time to call back is", so 
there is some hope that an un-upgraded caller is more likely to do the 
right thing.

Given the admittedly restricted review of the WG archive that I did, I 
didn't see anything to indicate that the WG fully considered the 
implications of 666 that I have outlined above. This is not simply a 
design preference; I believe the design of the proposed mechanism 
doesn't accomplish the goal and actually does some harm. Overall, 666 
damages interoperability by introducing an ambiguous piece of 
information, which will lead to potential data loss (i.e., improperly 
applied heuristics), and will require adding a header in the future in 
order to accomplish the real goal. Adding a header is a simple 
mechanism, accomplishes the desired task, has extensibility, and doesn't 
cause the problems that 666 does. Please reconsider this, drop this 
document, and replace it by adding real semantics to the 603 response 
with an extensible header. It's a quick document to write (a bunch of 
the text in the current document can be reused) and it will not suffer 
the problems that 666 introduces. Otherwise, we're going to be right 
back where were when we started, needing to add a mechanism so that the 
user can really indicate what they mean. This is the wrong solution.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]

On 7 Mar 2017, at 18:23, The IESG wrote:

> The IESG has received a request from the Session Initiation Protocol 
> Core
> WG (sipcore) to consider the following document:
> - 'A SIP Response Code for Unwanted Calls'
>   <draft-ietf-sipcore-status-unwanted-04.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2017-03-21. Exceptionally, comments may 
> be
> sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines the 666 (Unwanted) SIP response code, 
> allowing
>    called parties to indicate that the call or message was unwanted.
>    SIP entities may use this information to adjust how future calls 
> from
>    this calling party are handled for the called party or more 
> broadly.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.