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.