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

[Pete Resnick <[e-mail]>]

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. - [phone]