Service URN draft-schulzrinne-sipping-service-00 Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu August 2005 IETF63 - ECRIT

Motivation If resolution done by proxy, needs to identify call needing resolution May pass outbound proxy Also, needed for subsequent proxies Context-dependent resolution context = location for now ECRIT SIP August 2005 IETF63 - ECRIT

SIP request 9-1-1 INVITE sip:fire@paris.ia.state.us To: urn:service:sos 123 Main, Paris, IA INVITE urn:service:sos To: urn:service:sos 123 Main, Paris, IA August 2005 IETF63 - ECRIT

Why a URN? Identifies a generic service, not a specific resource Uses mapping protocol: {identifier, location}  URL(s) Can be used anywhere a URN/URL is allowed, e.g.: web pages result returned by mapping protocol request and To URI in SIP August 2005 IETF63 - ECRIT

URN structure urn:service:sname.subsname… urn:service:sname reaches any service of type ‘sname’ August 2005 IETF63 - ECRIT

Resolution Each top-level service type can define its own resolution mechanism might try default protocol if unknown Might be operated by different entities Each sub-service can have its own tree e.g., sos.fire may have different service boundaries than sos.police August 2005 IETF63 - ECRIT

Registering services Same issue as for registering services in mapping protocol without URN Define set of initial sos.* services (fire, police, …) Other top-level services possible e.g., urn:service:repair or urn:service:government.city August 2005 IETF63 - ECRIT

Alternatives lump:sos or lump:sos@example.com tel:911;context=+1 specific to resolution protocol does not fit SIP request URI tel:911;context=+1 hundreds of such identifiers, possibly changing  hard to recognize reliably how does end device determine context? sip:sos@home-domain.com backward-compatible safe: can test home proxy violates proxy behavior rules: non-domain proxy may attempt mapping assigns meaning to user part August 2005 IETF63 - ECRIT