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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



For some background - there was quite a bit of DISPATCH WG discussion on the use of the 666 response code to indicate that a call is unwanted, but it revolved around the use of a 6xx type of response vs. a 4xx response code.

How the choice might be presented to the end user was also discussed, although SIPCORE and DISPATCH WGs don't focus on GUI stuff. When the end user receives a call, they could select a "Block Caller" button on their cell phone just like they can select "Send to Voice Mail". The application on the phone would then generate the 666 response code, but the app would be very unlikely to show this code to the end user. On the caller's end, their app may not show them anything more than their call failed. Realistically, the response code would be seen only in diagnostics.

I took a look through the IETF archives for other uses of 666. 666 comes up occasionally in mailing list discussions as a foo/bar-type placeholder. RFC 7999 specifies the BGP community BLACKHOLE and its value, where "the low-order two octets in decimal are 666, a value commonly associated with BGP blackholing among network operators."

That said, there's plenty of space in the SIP 6xx response code range for an alternate response code to be selected if we think this will likely make end users uncomfortable.

Regards,

Jean

On 3/20/17 9:23 AM, Dale R. Worley wrote:
Denis Ovsienko <denis@xxxxxxxxxxxxx> writes:
If you mind people that take the Bible and its teachings seriously, it
will be easy for them to see it as a personal insult if their phone
receives and displays the message as it is proposed, as well as if
their phone sends such a message on their behalf. This is not specific
to SIP, the same conflict may be caused by a snail mail post, except
in real-time communications people have less time to think and step
back from the situation.

That seems to be a valid consideration to me:  Embedding
culturally/religiously/politically symbolic identifiers in a protocol in
a way that end users will at least occasionally see is probably not a
good idea.  It's clear even to me that a flippant reference to the
Prophet is asking for trouble, and it seems like we should take
references to the Number of the Beast seriously, given its long history
as a politically powerful symbol.

As an additional consideration, the document implies that the user
receiving the "unwanted" call has a good reason and the user placing
the call does not have it, as in spam calls.

I'm not current on the document, but my understanding is that it makes
clear that the response code is *in the opinion of the recipient* and
must be interpreted as such.  And indeed, that the recipient may have
triggered the response accidentally.

Besides the end users, there is the technical audience, both inside
and outside of IETF. This audience expects a certain level of
professionalism from IETF Standard Track publications. By not meeting
those expectations this publication would disappoint the engineers too
and lower their motivation to contribute. Simply put, the number of
people that think "IETF has less respect to its intended audience than
I used to think. They don't make Internet better, they are
whim-driven, now that I know it, I better stay away." will
increase. And they will actually stay away regardless if things
improve afterwards.

I think the evidence is that seriousness is not required to attract
technical talent to the IETF.  (See RFCs 439, 527, 748, 968, 1097, 1149,
1216, 1217, 1313, 1437, 1438, 1605, 1606, 1607, 1776, 1882, 1924, 1925,
1926, 1927, 2100, 2321, 2322, 2323, 2324, 2325, 2410, 2549, 2550, 2551,
2795, 3091, 3092, 3093, 3251, 3252, 3514, 3751, 4041, 4042, 4824, 5241,
5242, 5513, 5514, 5841, 5984, 6214, 6217, 6592, 6593, 6919, 6921, 7168,
7169, 7511, and 7514.)  However, there might be a public relations
problem concerning management, politicians, etc.

Dale

_______________________________________________
sipcore mailing list
sipcore@xxxxxxxx
https://www.ietf.org/mailman/listinfo/sipcore





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]