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

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@ovsienko.info> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>