Hi Pete
y
I quite agree with you. Instead of proposing a new response code like 666,
it would be better to add or rather propose a new header and add it to 603
response.
Regards
Ranjit
On Tue, Mar 21, 2017 at 10:49 AM, Pete Resnick
<presnick(_at_)qti(_dot_)qualcomm(_dot_)com>
wrote:
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 <(858)%20651-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.
_______________________________________________
sipcore mailing list
sipcore(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sipcore