Subject: [Sipping] Concern within sos ID - user addresses reserved

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Feb 2004 15:55:01 -0600

I have an concern within the new sos ID, and that concern is in section 4.1 
- which reserves the following additional user addresses:

	sos.fire	fire brigade
	sos.rescue	ambulance (rescue)
	sos.marine	marine guard
	sos.police	police (law enforcement)
	sos.mountain 	mountain rescue

as I have little confidence that Joe Citizen will be generally capable to 
choose the correct one given their emergency experience. If these addresses 
are intended for between two ERCs (for a call transfer, for example) - I 
don't see the text stating that here.

My issue is not really with the reservation of the user addresses, but with 
the lack of semantics and potential drawbacks surrounding using one of 
these when more than one should have been contacted (that a multipurpose 
ERC could determine by asking the right questions) or if the wrong one was 
dispatched because not enough was asked of the person in distress.

I think that if Joe Citizen is educated enough to call the *right* response 
center (say fire vs. mountain rescue) - then I retract this concern

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
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: David Oran <[email-masked]>
Date: Tue, 10 Feb 2004 17:13:52 -0500

--On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" 
<[email-masked]> wrote:

> I have an concern within the new sos ID, and that concern is in section
> 4.1 - which reserves the following additional user addresses:
>
> 	sos.fire	fire brigade
> choose the correct one given their emergency experience. If these
> addresses are intended for between two ERCs (for a call transfer, for
> example) - I don't see the text stating that here.
>
I thought this was just to reflect current practice in places that already 
have different numbers for the different emergency services. Is your 
concern that the *current* numbers are understood by joe citizen but these 
are not? If so, the UA can just do the mapping as it has to do already for 
911->sos@domain.

> My issue is not really with the reservation of the user addresses, but
> with the lack of semantics and potential drawbacks surrounding using one
> of these when more than one should have been contacted (that a
> multipurpose ERC could determine by asking the right questions) or if the
> wrong one was dispatched because not enough was asked of the person in
> distress.
>
If these were all we had and there were no generic sos@domain I think this 
would be a fairly large concern. Also concerning would be a deployment in a 
geography that only had the generic sos@domain and there was no AoR mapping 
of sos.*@domain -> sos@domain.

> I think that if Joe Citizen is educated enough to call the *right*
> response center (say fire vs. mountain rescue) - then I retract this
> concern
>
I doubt this is a good assumption, but what's the alternative in places 
that have already decided to have separate AoRs (service codes in 
PSTN-speak) for separate emergency service classes?

Dave.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Feb 2004 17:11:15 -0600

Comments in-line

At 05:13 PM 2/10/2004 -0500, David Oran wrote:

>have different numbers for the different emergency services.

This was not articulated, if intended

>Is your concern that the *current* numbers are understood by joe citizen 
>but these are not? If so, the UA can just do the mapping as it has to do 
>already for 911->sos@domain.

I'm concerned that, for example in the US, that Joe Citizen needs to learn 
911 as general purpose, 912 is police, 913 is fire, etc...

How is someone to dial into numeric keypad anything other than 911 in the 
US (and I'm picking on the US here)?

>would be a fairly large concern.

I'm not as much saying that the additional user addresses need necessarily 
be removed, just would like more usage text on how/when/where this could be 
used, with a potentially a "pitfall considerations" section for the 
ramifications of if the wrong organization was contacted and that delayed 
the proper help... that is, unless I'm the lone voice with this opinion.

>Also concerning would be a deployment in a geography that only had the 
>generic sos@domain and there was no AoR mapping of sos.*@domain -> sos@domain.
>

Add the text saying this, and this thread wouldn't have been started....

cheers,
James

                                *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Feb 2004 23:04:14 -0500

> This was not articulated, if intended

I added

This convention is not meant to
encourage end users to select emergency services where a uniform ECC
address for all such services exist. Rather, these identifiers reflect
current practice in jurisdictions that already have different
numbers for the different emergency services.

Hope that helps.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Feb 2004 10:45:29 -0500

>         sos.mountain    mountain rescue

The second sub-address seems vague to me.  Rescue could mean many 
things.  Perhaps, I need to be rescued from a fashion emergency. :)  Would 
something like:

         sos.medic        medical (doctor, nurse, paramedic team)

be more descriptive?

Also, with respect to registrations, I could see commercial interests 
wanting to get into the act, such as an sos.fashion that I hinted at 
above.  Is there some guidance necessary to IANA?  Do we expect that the 
IETF WGs will act as arbiters for this?

Second, wrt location information reporting, is there any need for a 
convention for providing a URL to which a receiving ECC can SUBSCRIBE to 
get location updates from either the UA or a network element that is doing 
triangulation.  I am wondering if something like the following can be 
inserted into the emergency INVITE:

Call-Info: <sips:[email-masked]> ;purpose=location

Mike