Subject: RE: [Sipping] Comment on draft-schulzrinne-sipping-sos-01.txt

From: "Francois Audet"<[email-masked]>
Date: Mon, 18 Mar 2002 12:39:06 -0800

Anything wrong with "emergency"?

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Monday, March 18, 2002 12:01
To: Christian Huitema
Cc: [email-masked]
Subject: Re: [Sipping] Comment on draft-schulzrinne-sipping-sos-01.txt

Christian:

I believe that is a common, but incorrect, perception. Merriam-Webster
defines SOS as:

--- begin quote ---
Pronunciation: "es-(")O-'es
Function: noun
Date: 1910
1 : an internationally recognized signal of distress in radio code · · ·
- - - · · · used especially by ships calling for help
2 : a call or request for help or rescue 
--- end quote ---

Indeed, http://www.uselessknowledge.com/word/sos.shtml addresses your
concern head-on. If you disagree, please provide a credible primary
source that refutes the article. The article says:

"The international morse code distress signal, S.O.S., is another "word"
with a false acronymic origin. S.O.S. does not stand for Save Our Souls,
Save Our Ship, Stop Other Signals, Sure Of Sinking, or any other phrase.

S.O.S. was chosen as the universal distress signal by the International
Radio Telegraph Convention of July 1908 because this combination of
letters, three dots followed by three dashes followed by three dots
(...---...), was easy to send and easily recognized. The letters
themselves are meaningless.

The first recorded mention of the false acronymic origin is in reference
to the Titanic sinking of 1912, which may account for its wide spread
and endurance."

Christian Huitema wrote:
> 
> The draft proposes the definition of a generic "distress signal" address
in
> SIP domains. While this is a good idea, I believe the specific choice of
the
> word "sos" is poor. This word comes from a religious tradition (save our
> souls) that is specific to some cultures. Choosing "mayday" would be more
in
> accordance with international practice.
> 
> -- Christian Huitema
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Mar 2002 14:50:05 -0600

Not that I want to get dragged into a discussion of terms (these are
usually lots of fun, but...): There's nothing wrong with emergency,
hilfe, mayday, or anything else except that

- they are, I believe, not recognized nearly as widely as sos;

- they are not as widely understood internationally. sos is, from all I
can tell, universal, mayday may be among a subset (aviators and
seafarers) but emergency is hard to spell for anybody whose primary
language is not English.

- most of them are much longer than 'sos'. I can type out 'sos' on a
12-button keypad, but imagine trying to type out 'emergency'.

> Francois Audet wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Mar 2002 19:55:34 -0500

Do we really expect that it will be *typed* at all?
If it has to be typed on a 12 button keypad, then about
99+% of the important users won't be able to do it!
(Try teaching that to your 3 year old or your grandmother.)

If we assume it doesn't have to be typed, then why does it
have to make certain words into reserved words. (I'll bet
there are a number of instances of "sos" as a username.)

How about a url parameter?

	INVITE <sip:anything@anywhere;emergency>

Or, since the domain is going to be ignored anyway,
why not use an url that doesn't have one, like the tel:
url? Extending its syntax won't take names from anyone.

	INVITE tel:sos

Or, invent a new url for the purpose:

	INVITE sos:whatever

Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Mar 2002 20:32:22 -0600

> (Try teaching that to your 3 year old or your grandmother.)

No, it typically won't be typed, but I certainly would want to make it
possible to do so, e.g., on PC-based software clients. Not all clients
will have a "911" or "112" button.

>         INVITE <sip:anything@anywhere;emergency>

The problem is that lookup is on the username, not the parameter, so
that this prevents some of the lookup mechanisms that have been
discussed previously.

> url? Extending its syntax won't take names from anyone.

It's not a telephone number, at least once we move to a non-PSTN
emergency call centers. Also has the lookup support problems mentioned
below - the first proxy to see this has to know this. The goal for the
sos mechanism is that I can predict that the 'sos' key is going to work
as long as it works at home and as long as I can send a SIP request to
my home domain.

> Or, invent a new url for the purpose:

Not backwards-compatible and thus requires that every proxy understands
it. The sip:sos@ has the advantage that it works if any proxy along the
path home can deal with it.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Mar 2002 16:35:56 -0500

> that this prevents some of the lookup mechanisms that have been

No matter what we do, this is a kludge. The lookup you suggest is one kind of kludge, while a lookup based on a parameter is just a different sort of kludge.

(Lookup on name is a kludge because it must be done even if the domain is not one serviced by this server. Normally in that case the name would be ignored and only the
domain would be used to route the message.)

It is at least as easy, if not easier, to implement a rule that says "if the request address contains an "emergency" parameter, direct it toward a provider of emergency
services regardless of the address itself."

> as long as it works at home and as long as I can send a SIP request to

OK, I will buy this argument against tel:sos and sos:

You seem to be assuming that this is always sent to some domain known to support it, and that proxies in other domains either process it normally or are kludged to process
this name in a domain they don't manage. The first possibility seems to contradict the goal that this be sent to the "nearest" emergency service. The alternative of a url
parameter works just as well.

This is not the most earthshattering of issues, but I have always felt that reserving words out of an otherwise open namespace is a bad idea.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Mar 2002 08:49:38 -0500

> services regardless of the address itself."

As proposed, every existing proxy can implement sos, without any code
changes. That's a worthwhile feature.

> This is not the most earthshattering of issues, but I have always felt that reserving words out of an otherwise open namespace is a bad idea.

There is a long history for this, dating back to 'postmaster' and
'hostmaster'. The problem is that you don't want something too special,
since everybody needs to be able to generate these names.