Subject: [Ecrit] comments on service-urn draft

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Mar 2006 12:39:50 -0500

>  Since service URNs are not routable, a proxy or user agent has to
>    translate the service URN into a routable URL for a location-
>    appropriate service provider, such as a SIP URL.  LoST [24] is one

s/URL/URI

> We discuss alternative approaches in Appendix A.  For example, the
>    tel URI [20] allows to express service codes such as "911" for
>    emergency services by adding a context parameter, but does not
>    address the problem of global validity.

this paragraph seems out of place to me; the text above and below talk 
about resolution mechanisms based on domain name and location 
respectively. This text is talking about alternative solutions to 
service-urn itself. I'd drop the paragraph entirely, since it almost 
seems to suggest that tel:911 is a valid solution as well.

> For SIP, the service URN will likely appear in either the request URI
>    or the To header field, depending on which SIP element recognizes the
>    request as identifying an emergency call.  If the mapping is done by
>    a proxy, the call may no longer be recognizable as an emergency call.

We need to make sure there is an unambiguous way to recognize the call 
as 911. Its clear that it needs to be r-uri and not To because proxies 
WILL be doing this. The traditional problem we've had with r-uri is that 
it is rewritten by proxies for both retargeting (truly sending to a new 
destination user, as in call forwarding) and call routing (delivering 
the request to a registered contact for that user). I'll note that my 
proposal at last ietf of not translating the r-uri, but rather pushing 
Route headers, would solve this problem.

>    offer such mechanisms.  The ECRIT working group is currently
>       discussing several approaches, including solutions based on DNS,
>       IRIS and a web-services protocol.  Software prototypes for some of
>       these are currently already available and are believed to be
>       readily developed.

this seems out of place for an IANA registration; which is permanent.

>  Identifier uniqueness considerations: A service URN identifies a
>       logical service, specified in the service registration (see IANA
>       considerations).  Resolution of the URN, if successful, will
>       return a particular instance of the service, and this instance may
>       be different even for two users making the same request in the
>       same place at the same time; the logical service identified by the
>       URN, however, is persistent and unique.

Right; I think the registration template is really aimed at discussing 
the last bit here. In particular, I think you need to say that service 
URN MUST be unique for each unique service, and that this is guaranteed 
through registration of each service within the service namespace.

>  Process of identifier assignment: Details of the service assignment
>       depend on the service and national regulations.  In general, it is
>       assumed that providers of services can register through a service
>       mapping mechanism for a particular service in a particular
>       geographic area.  The provision of some services may be restricted
>       by local or national regulations.  (As a hypothetical example,
>       providing emergency services may be restricted to government-
>       authorized entities, which may limit the region where each entity
>       can advertise its services.)  The rules for each service are
>       described in a service-specific document.

true, but your text here is addressing how the service URN is mapped to 
a particular instance of the service (through LoST or NAPTR or 
whatever). I think the real issue is how new services themselves are 
registered. I had assumed this was through a standards track RFC which 
defines services, but that probably requires some discussion.

>   by the mapping protocols, an instance of a Resolution Discovery
>       System (RDS) as described in RFC 2276 [3].  There could be several
>       such mapping protocols in concurrent use, as long as there are
>       reasonable guarantees that all services are available in all
>       mapping protocols.  Section 4 describes the DDDS service that uses
>       DNS NAPTR records to find an instance of a mapping service.

I doubt this is true; I would think that some services will be available 
from some mapping protocols, others from different ones. For example, 
some services are inherently location based and would be available from 
location oriented resolution services like what ecrit is doing. Others 
are going to be domain specific and would only be from there.

So, there is a real issue here about how you know which mapping services 
are available for a particular service URN. Maybe this is defined by the 
service URN registration itself?

>  For example, a user agent could request to be routed to marine rescue
>    by including the following SIP header field:
> 
>      Accept-Contact: *;sip.service="urn:service:sos.marine"

This is not an unreasonable thing to do; the problem is that it buries 
an important identification (that this is an emergency call) deep within 
a header field used for many other purposes. So every proxy will need to 
inspect the accept-contact for this service value?

I rather prefer request-URI as an in-your-face unambigous identifier.

> 4.2  First Well Known Rule
> 
>    The first well known rule extracts a key from the AUS.  For this
>    application, the first well known rule extracts the service portion
>    from the URN, i.e., the "service" part described in Declaration of
>    Syntactic Structure (Section 2).

So, not the sub-service?

>  In summary, a client that wants to resolve a service URN obtains a
>    domain name through a variety of means, looks up the NAPTR record for
>    the resolution service and used the regular expression in that record
>    to transform the service URN into a protocol URL that leads to the
>    mapping service. 

Ah.. I had misunderstood the use case for the DDDS service. I thought 
the DDDS application was to actually get to the service URI, i.e.:

urn:service.pizza at provider.com -> sip:[email-masked]

rather than getting the mapping service.

If you are using DDDS to get the mapping service URL (a reasonable 
idea), then the issue about needing to have each service mappable 
through each mapping service goes away.

>       prevention hotline.
>    urn:service:sos.mental-health The 'mental-health' service refers to
>       the "[d]iagnostic, treatment, and preventive care that helps

why is [d] in square brackets?

> 5.2  SIP Media Feature Tag Registration:  Service
> 
>    This specification defines an additional media feature tag, extending
>    the SIP tree entries described in [8] and following the registration
>    process in Section 12.1 of that document.  This section serves as the
>    IANA registration for the service feature tags, which are made into
>    the SIP media feature tag tree.
> 
>    Media feature tag name: sip.service
>    ASN.1 Identifier: New assignment by IANA.

If we go this way, you need to actually provide the ASN.1 identifier.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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