ietf
[Top] [All Lists]

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

2017-03-21 12:06:14
Pete,

Joining this conversation late - apologies if it has already been discussed.

If you are proposing using a SIP response code  603 and with a header field
Decline-Type: spam, the problem with this is that in SIP, failure responses
(non-2xx) are delivered hop-by-hop and not end-to-end.  This means that
although the first hop (proxy) will get the Decline-Type:spam header field,
any future hops will not.  Instead, they will just get the 603.

A different response code such as 666 will be conveyed end-to-end, so every
proxy and the calling UA will get the semantics.

- Alan -

On Tue, Mar 21, 2017 at 9:51 AM, Pete Resnick 
<presnick(_at_)qti(_dot_)qualcomm(_dot_)com>
wrote:

Just replying to the points in your message (trimming as I go along):

On 21 Mar 2017, at 11:17, Henning Schulzrinne wrote:

My take of the discussion was that a simple mechanism that reflects
plausible and likely UI approaches was preferable to a more complex
mechanism.


First, there is nothing complex about adding a header that says,
"Decline-Type: spam" to 603. It is extremely simple, accomplishes exactly
the same result, reflects the one envisioned plausible and likely UI, and
has the added advantage of extensibility.

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.


The problem there is that you then will have two different ways of
expressing "spam", adding yet more ambiguity. It means that the implementer
has to know whether they're talking to a 666 implementation that does or
does not know about the additional parameter to understand what the
behavior will be. We've constantly faced this problem in IMAP over the
years and it's made for horrible implementations.

Better to do the simple thing first and not end up with two incompatible
ways to do the same thing in the future.

Yes, the idea was to model the (apparently near-universal) notions of the
email spam button.


Simply achievable with 603 and "Decline-Type: spam". The only additional
complexity is to create the IANA registry for future decline types. I'm
only suggesting this document defining the one right now.

The goal was never to create a full-fledged API for rejecting classes of
calls or otherwise controlling the behavior of voice spam filters.


Nor am I proposing such an API. Sure, pieces of this (and Call-Info
labeling) might be useful for such a thing later, but I have no interest in
such a thing now.

In practice, users will only be willing to spend a limited amount of time
on feedback for unwanted calls.


Again, the mechanism I propose does not add to that limited time. It
functions, in that scenario, exactly like 666. The difference is only in
extensibility (and avoids the potential pitfalls I mentioned earlier).

Adding parameters to existing status codes can be done, but that seems
more a matter of design taste.


As I said quite clearly, it's not a design matter. Using a separate status
code to mean "decline, with additional semantics" has side effects, because
you already have a status code for decline. Please re-read my explanation.

After all, we could then dispense with all specific codes and just use
100, 200, 400, 500 and 600, each with headers attached.


No, that absolutely does not follow. A layered approach of status codes
for broader semantic values and headers for specialized processing works
incredibly well. The problem arises when you introduce a status code that
does not give the basic processing engine enough information to go on.

What you want in this case is to have the default behavior be "decline",
as per the status code, and then have some side processing to figure out
whether to deposit information into a spam analysis engine, or hand it off
to some other process that does different sorts of things, based on the
additional semantic information in the header. That's a good division of
labor.

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.


Please see my earlier comments on this particular status code: It
increases semantic ambiguity, it increases the possibility for data loss,
and it limits future extensibility.

Again, it's not clear that you've fully understood and considered what I
wrote.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

_______________________________________________
sipcore mailing list
sipcore(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sipcore

<Prev in Thread] Current Thread [Next in Thread>