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

[Ranjit Avasarala <[e-mail]>]

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 <[e-mail]>
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. - [phone] <(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
> [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.
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>