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

[Alan Johnston <[e-mail]>]

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