Denis Ovsienko <denis(_at_)ovsienko(_dot_)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