|
Pete, I believe we discussed several of these issues in the meeting and the early in-person discussion, but the discussion was never quite focused, so it’s probably
easy to miss in the archives. My take of the discussion was that a simple mechanism that reflects plausible and likely UI approaches was preferable to a more complex mechanism. 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. Yes, the idea was to model the (apparently near-universal) notions of the email spam button. Indeed, early phone UIs that are emerging do seem to take the same
approach, such as the Google Android dialer UI. It offers exactly one option – swipe up to accept and a red (X) button to block calls like that. The goal was never to create a full-fledged API for rejecting classes of calls or otherwise controlling the behavior of voice spam filters. I don’t think that’s
appropriate for a call response as that would seem to be better done via a web interface or other API-based configuration option. For example, such web UIs may offer more in-depth options such as “no charities, except X” or “no surveys except those labeled
as high-quality by trusted organization Y”. I don’t think we are anywhere close to knowing what this should be. My sense is that, given UI and user patience limitations, no deployed system actually uses the Retry-After header, so all 603’s seen in the wild are devoid of
this indicator. In practice, users will only be willing to spend a limited amount of time on feedback for unwanted calls. Analytics will be much better in sorting out the “annoying
ex” from “annoying time share seller” than asking users to fill out a survey after the call – the former will be indicated by exactly one person only, the latter by hundreds or thousands. For what it’s worth, the same potential problems exists in email, but
doesn’t seem to have caused any actual problems for spam filters since the statistical signature looks quite different. Adding parameters to existing status codes can be done, but that seems more a matter of design taste. After all, we could then dispense with all specific codes
and just use 100, 200, 400, 500 and 600, each with headers attached. This has not been the SIP design approach in the past. 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. Henning From: Pete Resnick [mailto:presnick@xxxxxxxxxxxxxxxx]
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 On 7 Mar 2017, at 18:23, The IESG wrote:
|