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