Subject: [Ecrit] Review of draft-ietf-ecrit-service-urn-04

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Aug 2006 12:11:37 +0200

Hi all,

I went through the draft-ietf-ecrit-service-urn-04 draft. To me the 
current version looks good even though there is no normative dependency 
on LoST. I only have some minor comments:

The draft says:
"
Availability of such service identifiers simplifies end system
    configuration.  For example, an IP phone could have a special set of
    short cuts, address book entries or buttons that invoke emergency
    services, as it would not be practical to manually re-configure the
    device with local emergency contacts for each city or town a user
    visits with his or her mobile device.  Also, such identifiers make it
    possible to delegate routing decisions to third parties and to mark
    certain requests as having special characteristics while preventing
    these characteristics to be accidentally invoked on inappropriate
requests.
"

[hannes] I cannot follow the argument. The service identifier provides 
benefits mostly for the entities in the network.

The draft says:
"
    The service URN is a protocol element and generally not expected to
    be visible to humans.  For example, it is expected that callers will
    still dial '9-1-1' in the United States to reach emergency services.
    In some other cases, speed dial buttons might identify the service,
    as is common practice on hotel phones today.  (Speed dial buttons for
    summoning emergency help are considered inappropriate by most
    emergency services professionals, at least for mobile devices, as
    they are too prone to being triggered accidentally.)  Rather,
    protocols would carry the service URN described here, allowing
    universal identification.  The translation of dial strings or service
    numbers to service URNs is beyond the scope of this document; it is
    likely to depend on the location of the caller and may be many-to-
    one.  For example, a phone for a traveler could recognize the
    emergency number for both the traveler's home location and the
    traveler's visited location, translating both to the same universal
    service URN, urn:service:sos.
"

[hannes] Based on the latest version of the ECRIT requirements draft I 
would change this paragraph to:
"
    The service URN is a protocol element and generally not expected to
    be visible to humans.  For example, it is expected that callers will
    still dial the emergency service number '9-1-1' in the United States 
to reach emergency services.
    In some other cases, speed dial buttons might identify the service,
    as is common practice on hotel phones today.  (Speed dial buttons for
    summoning emergency help are considered inappropriate by most
    emergency services professionals, at least for mobile devices, as
    they are too prone to being triggered accidentally.)  Rather,
    protocols would carry the serice URN described here, allowing
    universal identification.

The translation of service dial strings or service
    numbers to service URNs at the end host is an implementation aspect 
and beyond the scope of this document. Furthermore, the service dial 
strings and the service numbers likely depend on the location of the 
caller and there may be a many-to-one relationship (i.e., many service 
numbers map to one service identified by a service identifier).  For 
example, a phone for a traveler could recognize the
    emergency service number for both the traveler's home location and the
    traveler's visited location, mapping both to the same universal
    service URN, urn:service:sos.
"

The draft says:
"
    Since service URNs are not routable, a SIP proxy or user agent has to
    translate the service URN into a routable URI for a location-
    appropriate service provider, such as a SIP URL.  LoST [19] is one
    resolution system for mapping service URNs to URLs based on
    geographic location.  It is anticipated that there will be several
    such systems, possibly with different systems for different services.

[hannes] What does the last sentence refer to? To which 'system' do you 
refer to? Maybe you want to say "It is anticipated that there will be 
several resolution protocols; possibly different onces used with 
different services".

The draft says:
"
Mapping protocols SHOULD always provide a mapping just
    for the top-level service even if sub-services are in use.  This
    mapping for the top-level service MAY also be used if an entity is
    presented with an invalid sub-service and presenting an error
    condition to the user is inappropriate, e.g., during an emergency.

[hannes] Don't use RFC 2119 language in the introduction section.

Why should a mapping protocol only provide a mapping just for the 
top-level services? I guess you want to say that "Even if sub-services 
are used, such as 'urn:service:sos.ambulance', it must be possible to 
ask for 'urn:service:sos' and to receive a response. Hence, the entity 
operating the service MUST ensure that top-level services lead to a 
result even if sub-services are used."

I think this sounds useful but it is not a function that can be provided 
by the mapping protocol itself. I guess it is necessary to target a 
different audience, namely those folks that deploy the stuff.

The draft says:
"
Process for identifier resolution:
Each top-level
       service can provide its own distinct set of mapping protocols.
       Within each top-level service, all mapping protocols MUST return
       the same set of mappings.
"
[hannes] I assume for the same input parameters. Still, why do you 
mandate this?

Section 4.4: Add the following note to the section:
"
[[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with the 
RFC number of this document and remove this note.]]
"

References: A number of references are a left-over from the previous 
draft version and not used in the draft anymore.

Ciao
Hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 26 Aug 2006 17:47:26 -0400

Thanks for the comments. Please see inline below.

On Aug 20, 2006, at 6:11 AM, Hannes Tschofenig wrote:

> current version looks good even though there is no normative  
> dependency on LoST. I only have some minor comments:
>
> The draft says:
> "
> [hannes] I cannot follow the argument. The service identifier  
> provides benefits mostly for the entities in the network.

I'm not sure I understand your concern. Do you disagree with the  
benefits stated? What sentence or statement would you like to change?

> [hannes] What does the last sentence refer to? To which 'system' do  
> you refer to? Maybe you want to say "It is anticipated that there  
> will be several resolution protocols; possibly different onces used  
> with different services".

That's roughly what this was meant to express.

> top-level services? I guess you want to say that "Even if sub- 
> services are used, such as 'urn:service:sos.ambulance', it must be  
> possible to ask for 'urn:service:sos' and to receive a response.  
> Hence, the entity operating the service MUST ensure that top-level  
> services lead to a result even if sub-services are used."
>
> I think this sounds useful but it is not a function that can be  
> provided by the mapping protocol itself. I guess it is necessary to  
> target a different audience, namely those folks that deploy the stuff.

This probably belongs in the LoST document in any event (and is  
already in the requirements document); I'll just delete this.

> [hannes] I assume for the same input parameters. Still, why do you  

I don't think you'd want a system where the answer to the query  
depends on which protocol you're using. Again, it might be  
unnecessary to specify this here, since this is more of a requirement  
for the mapping protocol.

> [[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with  
> the RFC number of this document and remove this note.]]
> "
>
> References: A number of references are a left-over from the  
> previous draft version and not used in the draft anymore.
>
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Aug 2006 22:05:28 +0200

Hi Henning,

> benefits stated? What sentence or statement would you like to change?

What about the following:
"
Availability of such service identifiers allows end systems to convey
information about the desired service to other communication entities.
For example, an IP phone could have a special set of short cuts, address
book entries or buttons that invoke emergency services. When such a
service identifier is put into the outgoing SIP message it allows SIP
proxies to unambiguously take actions, as it would not be practical to
configure them with dial strings and emergency numbers used throughout
the world. Hence, such service identifiers make it possible to delegate
routing decisions to third parties and to mark certain requests as
having special characteristics while preventing these characteristics to
be accidentally invoked on inappropriate requests.
"

> 
>>
>> The draft says:
>> "
>>    From [email-masked] Sun Aug 27 16:05:56 2006
Date: Sun, 27 Aug 2006 22:05:28 +0200
From: Hannes Tschofenig <[email-masked]>
To: Henning Schulzrinne <[email-masked]>
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-service-urn-04
Cc: ECRIT <[email-masked]>

Hi Henning,

> benefits stated? What sentence or statement would you like to change?

What about the following:
"
Availability of such service identifiers allows end systems to convey
information about the desired service to other communication entities.
For example, an IP phone could have a special set of short cuts, address
book entries or buttons that invoke emergency services. When such a
service identifier is put into the outgoing SIP message it allows SIP
proxies to unambiguously take actions, as it would not be practical to
configure them with dial strings and emergency numbers used throughout
the world. Hence, such service identifiers make it possible to delegate
routing decisions to third parties and to mark certain requests as
having special characteristics while preventing these characteristics to
be accidentally invoked on inappropriate requests.
"

>> you refer to? Maybe you want to say "It is anticipated that there will 
>> be several resolution protocols; possibly different onces used with 
>> different services".
> 

I made a mistake when I wrote the comment. What do you have in mind with
the last sentence?

> This probably belongs in the LoST document in any event (and is already 
> in the requirements document); I'll just delete this.
> 
OK.

> I don't think you'd want a system where the answer to the query depends 
> on which protocol you're using. Again, it might be unnecessary to 
> specify this here, since this is more of a requirement for the mapping 
> protocol.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 27 Aug 2006 16:22:48 -0400

> be accidentally invoked on inappropriate requests.

This works for me.

> I made a mistake when I wrote the comment. What do you have in mind  

This was an attempt at political correctness when written, i.e., when  
there were several candidate proposals for URN resolution. More  
importantly, one could imagine that some places would use a  
proprietary back-end protocol in SIP proxies to do look-ups. We can't  
prevent this, but obviously don't need to encourage it.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Aug 2006 22:35:03 +0200

> importantly, one could imagine that some places would use a proprietary 
> back-end protocol in SIP proxies to do look-ups. We can't prevent this, 
> but obviously don't need to encourage it.
Understood. Fine.