Re: Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard
2017-03-21 10:51:00
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. - +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 mailing lists by 2017-03-21. Exceptionally, comments may
be
sent to 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/
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.
|
|