ietf
[Top] [All Lists]

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

2017-03-21 11:18:11
Pete,

I believe we discussed several of these issues in the meeting and the early 
in-person discussion, but the discussion was never quite focused, so it's 
probably easy to miss in the archives. My take of the discussion was that a 
simple mechanism that reflects plausible and likely UI approaches was 
preferable to a more complex mechanism. Nothing prevents adding information to 
the 'unwanted' status code in the future, should there be a need. As you 
indicate, the Call-Info labeling may well inform such an effort.

Yes, the idea was to model the (apparently near-universal) notions of the email 
spam button. Indeed, early phone UIs that are emerging do seem to take the same 
approach, such as the Google Android dialer UI. It offers exactly one option - 
swipe up to accept and a red (X) button to block calls like that.

The goal was never to create a full-fledged API for rejecting classes of calls 
or otherwise controlling the behavior of voice spam filters. I don't think 
that's appropriate for a call response as that would seem to be better done via 
a web interface or other API-based configuration option. For example, such web 
UIs may offer more in-depth options such as "no charities, except X" or "no 
surveys except those labeled as high-quality by trusted organization Y". I 
don't think we are anywhere close to knowing what this should be.

My sense is that, given UI and user patience limitations, no deployed system 
actually uses the Retry-After header, so all 603's seen in the wild are devoid 
of this indicator.

In practice, users will only be willing to spend a limited amount of time on 
feedback for unwanted calls. Analytics will be much better in sorting out the 
"annoying ex" from "annoying time share seller" than asking users to fill out a 
survey after the call - the former will be indicated by exactly one person 
only, the latter by hundreds or thousands. For what it's worth, the same 
potential problems exists in email, but doesn't seem to have caused any actual 
problems for spam filters since the statistical signature looks quite different.

Adding parameters to existing status codes can be done, but that seems more a 
matter of design taste. After all, we could then dispense with all specific 
codes and just use 100, 200, 400, 500 and 600, each with headers attached. This 
has not been the SIP design approach in the past. I don't see the problem with 
a new status code - we routinely add them and the mechanism of handling unknown 
ones are quite clear.

Henning

From: Pete Resnick [mailto:presnick(_at_)qti(_dot_)qualcomm(_dot_)com]
Sent: Tuesday, March 21, 2017 11:50 AM
To: ietf(_at_)ietf(_dot_)org
Cc: draft-ietf-sipcore-status-unwanted(_at_)ietf(_dot_)org; 
ben(_at_)nostrum(_dot_)com; sipcore(_at_)ietf(_dot_)org; Adam Roach 
<adam(_at_)nostrum(_dot_)com>; sipcore-chairs(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP 
Response Code for Unwanted Calls) to Proposed Standard


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/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.qualcomm.com_-257Epresnick_&d=DwMFAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ZsmZFFMTXYB11wQOAzumSkgmvAzLj_2Hn4Z58HTMBvE&s=tlEJ9fjpmuZLfEjlkXtf4tDxw4Bni6wK1arhT_2Zddg&e=>
Qualcomm Technologies, Inc. - +1 (858)651-4478

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
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by 
2017-03-21. Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org<mailto:iesg(_at_)ietf(_dot_)org> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=DwMFAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ZsmZFFMTXYB11wQOAzumSkgmvAzLj_2Hn4Z58HTMBvE&s=hy8D0YsflQHIyKQiWo_fdbP4Ah_Ej6vFervxifuVyJU&e=>

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ballot/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_ballot_&d=DwMFAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ZsmZFFMTXYB11wQOAzumSkgmvAzLj_2Hn4Z58HTMBvE&s=kX6Ocb3l9f7SR-kaqL7gkLgF0bj11sm1YalrviswYQY&e=>

No IPR declarations have been submitted directly on this I-D.
<Prev in Thread] Current Thread [Next in Thread>