Subject: AW: [Ecrit] SOS and service URN drafts

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 26 Oct 2005 10:45:28 +0200

hi henning, 

thanks for the draft update. these documents are important for our work and we also have an charter item about it:
"
Aug 05    A BCP describing how to identify a session set-up request is to an emergency response center  
"

the question therefore is only: do we only need one or both (and how do they relate to each other)? 

additionally, we need to clarify where the work has to be done - ecrit or sipping. but that's probably the least important question. 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Henning Schulzrinne
> Gesendet: Mittwoch, 26. Oktober 2005 02:24
> An: [email-masked]
> Betreff: [Ecrit] SOS and service URN drafts
> 
> 
> I have re-submitted slightly changed versions of older drafts:
> 
> http://www.cs.columbia.edu/sip/draft/sos/draft-ietf-sipping-so
s-01.html

is a somewhat updated version of the long-expired 'SOS' draft that's 
been ghosting around the I-D archives for a while. Besides updating some 
references, I've trimmed material that no longer seemed to belong there. 
It still references an architecture draft, which would need a major 
overhaul or (more likely) be dropped from the reference list, but I 
believe it is otherwise complete. Section 5 may belong into 
sinnreich-sipdev-req or the oft-cited "BCP" instead.

http://www.cs.columbia.edu/sip/draft/service/draft-schulzrinne-sipping-service-01.html

is a minor keep-alive editorial update of the service URN draft.

If possible, I'd like to discuss both in Vancouver, so that I some idea 
whether to pursue zero, one or both of these proposals further.

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Oct 2005 09:33:25 -0400

> the question therefore is only: do we only need one or both (and how do they relate to each other)? 

The 'sos' draft has a brief description of the trade-offs involved 
between the two solutions. Here's my slightly longer take:

- "urn:service" is a long-term solution that better fits the general 
URN/SIP model and can be applied to other problems beyond emergency 
calling, but requires infrastructure upgrades throughout, from UAs to 
proxies and maybe other entities such as SBCs. It is 
protocol-independent as long as a protocol supports URLs. I think it is 
also the correct solution to identifying services within the mapping 
protocol, even if 'sip:sos@' is used in the protocol request itself.

- "sip:sos" is immediately deployable and should work with just about 
anything out there that does SIP. It doesn't extend as nicely to other 
services and is obviously SIP-specific.

I think the best way forward is to progress both; the additional 
implementation complexity is rather modest and I think there's a 
reasonable transition path. The only issue is that UAs that want to 
support the service URN would need to be able to fall back to 'sip:sos@' 
if their outbound proxy returns a 404. The 'sos' draft can then be 
labeled appropriately and refer to the 'service' draft as the 
longer-term solution. The 'sipdev-req' document in SIPPING can then 
include the appropriate wording to guide implementors.

The 'sos' draft also has a brief section on other approaches that have 
been suggested in the past and why I believe that they are probably not 
as good. Thus, I'd appreciate if people who have other suggestions would 
consult that section so that we don't have to repeat discussions from 
eons ago.

The caller preferences indication in the 'sos' draft is largely 
independent of the URL convention and thus probably should be discussed 
separately. (It is needed for the sip:sos draft, however, if we want to 
distinguish different emergency services.)

As I mentioned earlier, I think both drafts are completely orthogonal to 
the mapping protocol and don't prejudice its evolution. We need call 
identification even while the "i2" solution is still being deployed. The 
longer we wait, the larger the likely mess.

Henning