Subject: [Ecrit] Comments on framework-03

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 12 Oct 2007 17:02:45 -0400

This is also a good document, and I only have a few comments.

I have a Word document with all the editorial/grammatical comments, that
I'll send directly to the authors (everyone should try typing
"uninitialized" 20 times, fast).
Barbara

---------------
Terminology

I recommend including "Uninitialized Device" in the terminology section.
Uninitialized Device:  A device that is not registered, or that doesn't
have valid call back identifiers. (??) [Should this be an "or" or an
"and"? I stole this from later in the text, but to be honest, I'm not
really sure what the definition is.]
----------------
3.  Overview of how emergency calls are placed
   o  It determines the PSAP's URI by querying the LoST mapping server
      with its location.

I recommend slightly modifying to include updating location, too: "It
updates its location, using the same methods as before, and updates the
cached PSAP URI by..."
-----------------
6.3.  Who adds location, endpoint or proxy
The calling network must provide another way for the device
   to learn the local dial string (and update it when the user moves to
   a location where the dial string(s) change) or do the dial string
   determination itself.

This would be nice. It works well in current cellular environments, but
isn't practical in an open Internet environment. I'd like to see the
verbiage toned back a little. Similar comment made against phonebcp.
------------------
6.10.  Location validation
"Test functions (Section 15) should also re-validate."

I don't understand what it is that this sentence says test functions
should do. Section 15 doesn't discuss location validation. Or is the
successful execution of a test a form of validation?
------------------
6.12.  Other location considerations
"Although support of TLS is mandatory in [RFC3261], many devices do not
support it.  Implementing location conveyance in SIP mandates inclusion
of TLS support."

RFC 3261 says "It is strongly RECOMMENDED that UAs be capable initiating
TLS". That doesn't quite sound like mandatory, to me. I'm aware of many
devices that intend to support IPsec, and not TLS. Anyway, I don't think
the 2nd sentence quoted above is true.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

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

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 15 Oct 2007 14:40:39 +0200

I read the framework document, too. Except editorial comments, I have
one problem with recognizing emergency calls and dial strings. The
framework document says:

1) Users are not expected to "dial" an emergency URN.

2) Having the home dial string work is optional.

3) The LoST response may contain the dial string for emergency calls
appropriate for the location provided.

Now, how can a user place an emergency call when the UA supports no
home dial string and the LoST response does not contain the visited
dial string?

Do I get here something wrong?
Karl Heinz

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 15 Oct 2007 15:14:45 +0200

Hallo Karl Heinz, 

> 1) Users are not expected to "dial" an emergency URN.
That's true because the emergency URN is somewhat difficult to dial
compared to an emergency dial string. 

urn:service:sos.police vs. 911

> 2) Having the home dial string work is optional.
I wonder why this is stated in the document given that it is quite easy
to accomplished. 

> appropriate for the location provided.
Right. This is for the visited emergency dial string. 

> Do I get here something wrong?
I need to check whether the document indeed says that the home emergency
dial string is optional. It shouldn't. 

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 15 Oct 2007 09:32:41 -0400

> dial string is optional. It shouldn't.
Yes, it's optional.  The local (visited) one is required.  Home is not.
When you roam to London, you dial 9-9-9, not your home number.

Supporting the home number is "nice to have".  Supporting the local number
is a hard requirement, sometimes a legal requirement.

Brian

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 15 Oct 2007 15:33:54 +0200

> urn:service:sos.police vs. 911

Of course!

> I wonder why this is stated in the document given that it is quite easy

Maybe because of dial plan conflicts of the home and visited country?

> Right. This is for the visited emergency dial string.

But there is just a "may". The serviceNumber in Lost is optional.

> dial string is optional. It shouldn't.

Chapter 5, end of the 3. paragraph: "Having the home dial string work
is optional."

karl heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 15 Oct 2007 09:47:23 -0400

The problem with writing this text is that the big bad IMS is out there.
IMS configures the local dial string into the UA not using LoST.

It works because of the relationship between the visited network and the UA.
That technique won't work in most other environments, because the
relationships are different.

I probably should make a pass through -phonebcp and find all the "SHOULDS"
and have text in -framework (and/or -phonebcp) that covers the cases where
it doesn't apply.

The problem is that it leads to pretty awkward wording.  

Brian

> -----Original Message-----
> From: Karl Heinz Wolf [mailto:[email-masked]]
> Sent: Monday, October 15, 2007 8:41 AM
> To: [email-masked]
> Subject: Re: [Ecrit] Comments on framework-03
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 15 Oct 2007 09:58:13 -0400

Hey! Not all IMS is big and bad. :)
I assume you're referring to 3GPP access networks, and not necessarily
IMS. Many companies intend to deploy IMS only within a core network
(i.e., a home IMS), with no need for or dependency on the existence of a
visited IMS network. 
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, October 15, 2007 9:47 AM
To: 'Karl Heinz Wolf'; [email-masked]
Subject: RE: [Ecrit] Comments on framework-03

It works because of the relationship between the visited network and the
UA.
That technique won't work in most other environments, because the
relationships are different.

I probably should make a pass through -phonebcp and find all the
"SHOULDS"
and have text in -framework (and/or -phonebcp) that covers the cases
where
it doesn't apply.

Brian

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 Oct 2007 10:43:27 -0400

My general observation is that a SHOULD in a document is  
underspecified unless there's a condition that indicates when the  
action asked for is not required. Omitting it is just punting. If you  
go by 2119, it also makes an implementation only conditionally  
compliant, even though there may be an alternate, equally-functional  
way of implementing a certain desirable outcome. In this particular  
case, we know the condition, so we should state it. It's not like IMS  
is some kind of secret.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 15 Oct 2007 10:52:05 -0400

You are, of course, correct.

And you did write "too many SHOULDs" in your last edit, which I actually
read as "too many SHOULDs without an explanation of why they are not MUSTs".

I guess I have to make a pass through and address those.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, October 15, 2007 10:43 AM
> To: Brian Rosen
> Cc: 'Karl Heinz Wolf'; [email-masked]

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Tue, 16 Oct 2007 10:07:38 +0200

Besides the troubles with home and visited dialplans, how can the
visited dialstring be figured out if the LoST response not necessarily
contains a dial string?

karl heinz

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 11:34:32 +0300

> visited dialstring be figured out if the LoST response not necessarily
LoST is the mechanism to obtain the visited emergency dial string.

Ciao
Hannes

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Tue, 16 Oct 2007 10:49:23 +0200

hi Hannes,

> LoST is the mechanism to obtain the visited emergency dial string.

But draft-ietf-ecrit-lost-06 says the service number is just optional:

   5.7. The Service Number: the <serviceNumber> Element

   The service number is returned in the optional <serviceNumber>
   element.

That's why I'm confused.

karl heinz

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 11:56:20 +0300

Hi Karl Heinz,

>    The service number is returned in the optional <serviceNumber>
LoST may also be used in cases where the dial string is not needed. For 
example, when LoST is used only to validate civic addresses then it is 
not needed.
Another example, when a proxy uses LoST for location based routing then 
the <serviceNumber> element will not be helpful.

The Phone BCP document should say: When LoST is used by the end host 
then the <serviceNumber> must be returned.

Does this make sense?

Ciao
Hannes

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Tue, 16 Oct 2007 11:15:18 +0200

> the <serviceNumber> element will not be helpful.

but it wouldn't harm, would it?

> then the <serviceNumber> must be returned.

how does the LoST Server know if a client or a proxy does the
findService request?

ciao
karl heinz

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 Oct 2007 08:12:53 -0400

>> ed. For

Not all services may have dial strings, at least in the long term.  
Remember that LoST can be used for things other than emergency calls.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 16 Oct 2007 09:40:49 -0400

I think this does make sense to discuss in -framework, with a rule in
-phonebcp. 

Brian

> Sent: Tuesday, October 16, 2007 8:13 AM
> To: Karl Heinz Wolf
> Cc: [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Oct 2007 10:38:24 -0400

I think what's unclear is exactly when serviceNumber is returned.  It 
seems like the document assumes that if there is a serviceNumber, it 
will be returned, but it doesn't make this explicit requirement.

You could imagine a LoST server that knows serviceNumbers but only 
returns a serviceNumber for, say, urn:service:sos, under the assumption 
that other services could be reached via that dial string (an assumption 
that works in the US, but not elsewhere).  This behavior is implicitly 
disallowed -- there's no way for the client to get the other numbers, 
since there's no request mechanism for that -- but still possible.

It seems like LoST requires one of the two following changes to address 
Karl Heinz's concern:
1) A clause in section 5.7 to say that if a LoST server has a 
serviceNumber, then it MUST return it.  (Possibly with one or two 
exceptions, like validation)
2) A mechanism for a client to explicitly request a service number be 
included in their findServiceResponse (and a mechanism for the server to 
indicate he has none).

I prefer option (1) because it is much simpler.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 17:45:15 +0300

Hallo Karl Heinz,

> but it wouldn't harm, would it?
No. It does not harm. I just wouldn't be needed by the proxy (in a 
normal setting where the end host provided the Service URN).
If you consider legacy clients then there is obviously the limitation 
that they wouldn't be able to learn the visited dial string 
automatically, they phone would not be able to recognize that this is an 
emergency call and the proxy might not recognize the emergency call 
either....

> how does the LoST Server know if a client or a proxy does the
It would only know in an environment, such as envisioned by the 3GPP IMS 
emergency services architecture or enterprise networks where these 
functions are provided "locally". In these architectures the LoST 
server, the proxy, and the location server are deployed locally and they 
would obviously know each other.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 17:49:38 +0300

I would feel much better to put such a statement into the Phone BCP.
That's the right place.

Richard Barnes wrote:
> returns a serviceNumber for, say, urn:service:sos, under the 
> assumption that other services could be reached via that dial string 
> (an assumption that works in the US, but not elsewhere).  This 
> behavior is implicitly disallowed -- there's no way for the client to 
> get the other numbers, since there's no request mechanism for that -- 
> but still possible.
>
> It seems like LoST requires one of the two following changes to 
> address Karl Heinz's concern:
> included in their findServiceResponse (and a mechanism for the server 
> to indicate he has none).
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 16 Oct 2007 11:02:34 -0400

I think it should be something like:
If there is a possibility of an endpoint or proxy needing the dial string it
MUST be returned.  If the configuration of the server and its clients limits
use to circumstances where the endpoint or proxy has other mechanisms to
determine the dial string, or the service URN supplied does not have a dial
string, or the use of the query is strictly for validation, then the
parameter need not be returned".

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2007 10:45 AM
> To: Karl Heinz Wolf
> Cc: [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Oct 2007 11:18:45 -0400

You can put it in phonebcp if you like, but it's a statement that 
applies to ALL LoST servers and ONLY to LoST servers.  So it seems like 
the LoST document would be the place to put it.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Oct 2007 11:39:31 -0400

> parameter need not be returned".

It seems to me like you're headed down same path as the "suppose you 
control every device on the network" special case.  As I've said before, 
making special exceptions for this case doesn't make any sense: If you 
control the whole system, then you can use things however you want, and 
we don't need to say anything about it.  And moreover, it tempts people 
to think they're in the special case when they might not be, possibly 
causing calls to fail as a result.

For example, how does the LoST server know there's NO possibility of the 
client needing a dial string?  Maybe it's in a walled-garden network (in 
which case, again, it can do whatever it wants), but maybe the operator 
just assumes that requests for certain URNs don't need dial strings. 
It's hard to differentiate between these two cases, so I tend to not to 
make special exceptions the non-standard case at all.

If you're going to add text to phonebcp, it should be simple:
"LoST servers MUST include service numbers whenever possible."

--Richard

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 16 Oct 2007 12:30:01 -0400

Hmmm. There are so many caveats, that I'm not really sure what it says.
Also, it sounds more like a requirement on the LoST server, than the
endpoint or proxy. Phonebcp doesn't have requirements for LoST servers,
so it seems out of place. 

In reading LoST, it appears that the endpoint and proxy have absolutely
no control over whether or not serviceNumber is returned. Clearly, they
have to do a findService request, that includes a location, and
emergency service URNs in <service>. But that's basically already
covered in phonebcp.

It seems like the requirement is that if a LoST server has
serviceNumbers defined for a requested service URN, for the location in
the request, then the LoST server MUST include those serviceNumbers in
its response.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 11:03 AM
To: 'Hannes Tschofenig'; 'Karl Heinz Wolf'
Cc: [email-masked]
Subject: RE: [Ecrit] Comments on framework-03

I think it should be something like:
If there is a possibility of an endpoint or proxy needing the dial
string it
MUST be returned.  If the configuration of the server and its clients
limits
use to circumstances where the endpoint or proxy has other mechanisms to
determine the dial string, or the service URN supplied does not have a
dial
string, or the use of the query is strictly for validation, then the
parameter need not be returned".

> >>>>>> read as "too many SHOULDs without an explanation of why they
are
> not MUSTs".
> >>>>>>> action asked for is not required. Omitting it is just punting.
If
> you
> >>>>>>> case, we know the condition, so we should state it. It's not
like
> IMS
> >>>>>>>> The problem with writing this text is that the big bad IMS is
out
> >>>>>>>> there.
> >>>>>>>> It works because of the relationship between the visited
network
> >>>>>>>> and the UA.
> >>>>>>>> and have text in -framework (and/or -phonebcp) that covers
the
> >>>>>>>> cases where
> >>>>>>>>> I read the framework document, too. Except editorial
comments, I
> have
> >>>>>>>>> one problem with recognizing emergency calls and dial
strings.
> The
> >>>>>>>>> 3) The LoST response may contain the dial string for
emergency
> calls
> >>>>>>>>> Now, how can a user place an emergency call when the UA
supports
> no

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Oct 2007 10:19:52 -0700

At 10:38 AM -0400 10/16/07, Richard Barnes wrote:
>I think what's unclear is exactly when serviceNumber is returned.  It seems like the document assumes that if there is a serviceNumber, it will be returned, but it doesn't make this explicit requirement.
>
>You could imagine a LoST server that knows serviceNumbers but only returns a serviceNumber for, say, urn:service:sos, under the assumption that other services could be reached via that dial string (an assumption that works in the US, but not elsewhere).  This behavior is implicitly disallowed -- there's no way for the client to get the other numbers, since there's no request mechanism for that -- but still possible.
>
>It seems like LoST requires one of the two following changes to address Karl Heinz's concern:
>1) A clause in section 5.7 to say that if a LoST server has a serviceNumber, then it MUST return it.  (Possibly with one or two exceptions, like validation)

So, I think this kind of statement does not belong in -framework; it *might* belong
in BCP.  I'm a little leery of it even there.  At the moment, it is up to the
folks configuring the LoST server to set up the data mapping.  In the case
above, where the LoST server returns 911 as a serviceNumber for urn:service:sos,
but does not return a serviceNumber for others, it may simply be because
the user should use the returned URIs instead.  The phrase "if a Lost server
has a serviceNumber, it MUST return it" specifies how someone should
set up the data mapping, and it might be taken to imply that someone deploying
lost needs to set up serviceNumbers for any service they deploy.  They don't,
as Henning already pointed out. 

If the serviceNumber is just a different way of invoking the same set of mechanisms
that would otherwise be reached through the URIs LoST returned, how is getting
the serviceNumber back all that important?  Are you assuming that there will be
LoST enabled devices that do not have the ability to invoke the URIs? 

Or are you assuming that there will be some difference between the procedures
used with serviceNumbers and the other URIs (e.g., someone dialing a
serviceNumber uses a service that is at least partially circuit-switched,
because it invokes the PSTN, as versus as more pure VoIP process)?

				regards,
					Ted

>2) A mechanism for a client to explicitly request a service number be included in their findServiceResponse (and a mechanism for the server to indicate he has none).
>
>-

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Oct 2007 13:45:56 -0400

Hi Ted,

> in BCP.  I'm a little leery of it even there. 

I was actually suggesting that it go in LoST, although I think it might 
fit better in the BCP, since it's less important for non-emergency 
numbers (although still relevant, e.g., for things like 4-1-1 or 3-1-1).

> ... it might be taken to imply that someone deploying

I think there's a misunderstanding here: I meant the phrase "If a LoST 
server has a serviceNumber" to mean "if there is a serviceNumber in the 
configured data mapping".  This presumes that operators will configure 
in all relevant service numbers, but doesn't require them to configure 
any.

The situation I want to avoid (and what I think got this started) is 
when the LoST server has a serviceNumber configured for an area, but 
doesn't return it for some reason -- this being one interpretation of an 
optional field.

> ... Are you assuming that there will be
> used with serviceNumbers and the other URIs?

In the context of an entity that is already LoST-capable, the 
serviceNumber is essentially a UI element.  It seems like the assumption 
is that users will want to continue to use serviceNumbers to refer to 
services, instead of URNs.  I believe that there are regulatory 
requirements for this UI (i.e., recognizing local numbers) in some 
jurisdictions.

Cheers,
--Richard

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Oct 2007 11:13:44 -0700

>I think there's a misunderstanding here: I meant the phrase "If a LoST server has a serviceNumber" to mean "if there is a serviceNumber in the configured data mapping".  This presumes that operators will configure in all relevant service numbers, but doesn't require them to configure any.
>
>The situation I want to avoid (and what I think got this started) is when the LoST server has a serviceNumber configured for an area, but doesn't return it for some reason -- this being one interpretation of an optional field.

Maybe I am confused here.  I am having troubling matching up "configured for an
area" being true and "returned" being false.  The configuration process tells
the server what to return for specific areas, so I'm really having trouble imagining
any conditions for "doesn't return it for some reason".  To put this another way,
doesn't this end up saying "you MUST return the values you were configured to
return"?

Sorry if I'm being dense.   It sounds like we at least agree that we're not trying
to have anyone set up new serviceNumbers for services they plan to deploy,
and that's important.  serviceNumbers are optional; you  should be able
to deploy a LoST/URI mapping without one.

>>LoST enabled devices that do not have the ability to invoke the URIs? Or are you assuming that there will be some difference between the procedures
>In the context of an entity that is already LoST-capable, the serviceNumber is essentially a UI element.  It seems like the assumption is that users will want to continue to use serviceNumbers to refer to services, instead of URNs.  I believe that there are regulatory requirements for this UI (i.e., recognizing local numbers) in some jurisdictions.
>

That's what is a bit tricky about all this, isn't it?  A UI element should be specific
to a particular UI context, but once someone is returned a serviceNumber, they
may well expect it to work on any device.  So if I start the call on my wifi phone,
get a serviceNumber of 112 for the area in which I'm roaming but lose battery
before the call goes through, I expect to be able to pick up the next phone I see
and dial 112. 

			regards,
				Ted

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Oct 2007 20:36:46 -0400

To try to capture the issue a little more succinctly, let me recall Karl 
Heinz's original observation.  The framework/phonebcp says:

1) Users are not expected to "dial" an emergency URN.  (i.e., they're 
expected to use a serviceNumber)

3) It's also optional for LoST to return a visited dial string (even 
when one exists at some layer) [per the LoST spec]

So there's an apparent contradiction: The device is expected to 
recognize emergency calls by the fact the the user has dialed a 
serviceNumber, but may not have one (either home or visited).  Thus, the 
goal of the requirement I proposed is to clarify that when (1) is true 
(i.e., there is a serviceNumber that the user is expected to dial to 
initiate emergency calls), that the LoST server (3) returns that 
serviceNumber.  This issue is based on the assumption (stated in the 
BCP) that users are expected to initiate emergency calls using a 
serviceNumber instead of a URN/URI.

As you point out, there's a second underlying assumption that LoST 
operators have configured in all available/relevant serviceNumbers.  But 
I'm trying to say that there needs to be a further requirement that the 
LoST server include the serviceNumber in all findServiceResponses.
This is slightly stronger than saying "you MUST return the values you 
were configured to return" -- it's more like saying "you MUST return ALL 
the values you were configured to return".  Kind of a "don't try to be 
too smart" rule.

Let me propose an example to try to clarify: Suppose that a LoST server 
had the following logical "mapping table"

Region  URN                  URI                serviceNumber
US      urn:service:sos	     sip:[email-masked]   911
US	urn:service:sos.fire sip:[email-masked]   911
US      urn:service:pizza    sip:papajohns.com  [none]

Now, say that the LoST server omits serviceNumber elements from 
findServiceResponses when validateLocation="true" -- in order to save a 
few bits here and there, assuming that clients are really after the 
validation, not the mapping.  This is allowed by the LoST spec (AFAICT). 
  However, it's also entirely reasonable that a client would only do one 
findService request in order to validate and get the mapping.  When this 
client and this server meet, and the client does a findService request 
with validateLocation="true", he doesn't get back a serviceNumber -- 
even though the LoST server knows that it's associated with the mapping.

This is not a huge problem, just a corner case that would be nice to 
rule out.

To reply specifically to your comments:

> The configuration process tells
> any conditions for "doesn't return it for some reason". 

The risk is that the server adds more logic besides "return this number 
for this area" based on other factors: Other parameters in the request 
(like validateLocation), whether the location is geodetic or civic, even 
the IP address of the requestor.

> It sounds like we at least agree that we're not trying
> and that's important. 

We definitely agree on that point.  I'm just trying to make sure that 
existing, configured serviceNumbers get maximal distribution.

Cheers,
--Richard

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Oct 2007 20:37:21 -0700

At 8:36 PM -0400 10/16/07, Richard Barnes wrote:
>To try to capture the issue a little more succinctly, let me recall Karl Heinz's original observation.  The framework/phonebcp says:
>
>1) Users are not expected to "dial" an emergency URN.  (i.e., they're expected to use a serviceNumber)
>
>3) It's also optional for LoST to return a visited dial string (even when one exists at some layer) [per the LoST spec]

("home" and "visited" are loaded terms; I'd prefer to avoid them).

Yes, this can happen.  It *will* happen whenever the folks maintaining
a LoST server include any service that does not have a serviceNumber.
(Such services may be reachable through some other UI element, such
populating a directory entry for "Poison Control" or "Suicide Prevention"
which has been pre-configured).  The most common emergency services
may get serviceNumbers, and the responders there may well get trained
on pushing things to more unusual responders when they get dialed.
But it is ultimately up to a jurisdiction to determine what serviceNumbers
get mapped to what service URNs.

Putting this another way, we may be able to reduce this happening when
a service URN  and serviceNumber are both available, but we should not be
blind to the fact it will happen.  We also may not be the right people to
judge whether a jurisdiction making this choice is making a mistake.

We also have to be aware that treating serviceNumber as a UI construct has
an inherent problem if there are multiple schemes returned (If I dial
the serviceNumber and there were sip, xmpp, and sms URIs present,  which
one gets picked?)

>So there's an apparent contradiction: The device is expected to recognize emergency calls by the fact the the user has dialed a serviceNumber, but may not have one (either home or visited).  Thus, the goal of the requirement I proposed is to clarify that when (1) is true (i.e., there is a serviceNumber that the user is expected to dial to initiate emergency calls), that the LoST server (3) returns that serviceNumber.  This issue is based on the assumption (stated in the BCP) that users are expected to initiate emergency calls using a serviceNumber instead of a URN/URI.
>
>As you point out, there's a second underlying assumption that LoST operators have configured in all available/relevant serviceNumbers.  But I'm trying to say that there needs to be a further requirement that the LoST server include the serviceNumber in all findServiceResponses.
>This is slightly stronger than saying "you MUST return the values you were configured to return" -- it's more like saying "you MUST return ALL the values you were configured to return".  Kind of a "don't try to be too smart" rule.

Well, serviceNumber is part of the mapping (like the URIs returned), and I really
have trouble picturing this problem arising, but if you wanted to include advice like:

"The <mapping> element returned with a response  to a request including a
 <validateLocation=true> should be identical to that returned as a response
to the same request where location validation is not requested."

I would be okay with that.  If there are other examples where you think
the responses might vary, we should discuss them. 

Thanks for your efforts to clarify the discussion.
					Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 16 Oct 2007 23:06:08 -0500

Looking at this from the outside in, it may be that we need a set of
very short BCPs that provide some guidance on good things to do when
provisioning a LoST server.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, 17 October 2007 1:37 PM
> To: Richard Barnes; Henning Schulzrinne; ECRIT
when
> one exists at some layer) [per the LoST spec]
> 
recognize
> emergency calls by the fact the the user has dialed a serviceNumber,
but
> may not have one (either home or visited).  Thus, the goal of the
> requirement I proposed is to clarify that when (1) is true (i.e.,
there is
> a serviceNumber that the user is expected to dial to initiate
emergency
> calls), that the LoST server (3) returns that serviceNumber.  This
issue
> is based on the assumption (stated in the BCP) that users are expected
to
> initiate emergency calls using a serviceNumber instead of a URN/URI.
> >
too
> smart" rule.
> 
> Well, serviceNumber is part of the mapping (like the URIs returned),
and I
> really
> have trouble picturing this problem arising, but if you wanted to
include
> advice like:

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 17 Oct 2007 07:49:48 -0400

This might be a better task for NENA.

-Marc-

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2007 12:06 AM
> To: Ted Hardie; Richard Barnes; Henning Schulzrinne; ECRIT
> Looking at this from the outside in, it may be that we need a 
> set of very short BCPs that provide some guidance on good 
> things to do when provisioning a LoST server.
> 
> Cheers
> James
> 
> 
> (i.e., they're
> > a service URN  and serviceNumber are both available, but we 
> should not
> be
> > blind to the fact it will happen.  We also may not be the 
> right people
> to
> > We also have to be aware that treating serviceNumber as a 
> UI construct
> has
> >  <validateLocation=true> should be identical to that returned as a 
> > response to the same request where location validation is not 
> > requested."
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 17 Oct 2007 06:55:13 -0500

That could be too.
I don't really have an opinion either way. I just think some degree of
clarification is required.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 17 October 2007 9:50 PM
> To: Winterbottom, James; 'ECRIT'
> > > >To try to capture the issue a little more succinctly, let me
recall
> > Karl
> > > operators have configured in all available/relevant
serviceNumbers.
> > But
> > > I'm trying to say that there needs to be a further requirement
that
> > > were configured to return" -- it's more like saying "you MUST
return
> > ALL

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 17 Oct 2007 08:34:03 -0400

NENA has determined that the 9-1-1 Authority (the government agency that
runs a local emergency call system) will be responsible to provide LoST
servers, and will have documents that describe what they should do and how
they should be configured.

I would like IETF documents to result in implementations that meet NENA's
requirements on the query side at least.  How the servers are actually
provisioned is NENA's problem I think.

However, I don't think this is enough, I think we need to leave proxy and
phone vendors, and network operators, with systems that work regardless of
where a subscriber roams or nomads (sic).  I think that means more text in
IETF documents.

I wonder if we should look at it as there is no harm in providing the number
even if the device has another way to get it (conflicts between them are a
problem, but too little information is much worse than too much here).  So,
maybe we should have the text be MUST except if the only operation is
validation or the service URN doesn't have a dial string to give.

Brian

> Sent: Wednesday, October 17, 2007 7:55 AM
> To: Marc Linsner; ECRIT

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Oct 2007 08:40:11 -0400

I agree with Brian's last statement. "MUST deliver if the service has  
one" seems easy enough to understand and implement. Even for  
validation, providing the service number is hardly onerous, so I'm  
not convinced that we need to create exceptions.

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 17 Oct 2007 09:29:35 -0400

Given that I had the same interpretation (mis-interpretation?) of the
LoST requirements in this area as Richard, I think it would be valuable
to be explicit about the LoST server returning serviceNumber values when
serviceNumber values are configured, in response to a findService
request.

Which is to say, I also agree with what Henning and Brian seem to be
saying. 

As a NIT, then, on LoST section 3 text, which says:
   <findService> and <findServiceResponse>

      A LoST client retrieves contact URIs based on location information
      and a service identifier with this request and response.  The same
      query type may also ask for location validation and for service
      numbers, either combined with a mapping request or separately.
      The details can be found in Section 8 and Section 8.4.

I think that the findService query type cannot "also ask" for service
numbers (since there's no way in the query to ask for service numbers).
Rather, the response may also include service numbers. Suggested
rewording: "The same query type may also ask for location validation,
either combined with a mapping request or separately. The response may
also include service numbers."

Barbara

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, October 17, 2007 8:40 AM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] Comments on framework-03

*****

---

From: Richard Barnes <[email-masked]>
Date: Wed, 17 Oct 2007 10:13:40 -0400

Yes.  Thanks Henning, that's what I was trying to get at earlier.
--RB

Henning Schulzrinne wrote:
> one" seems easy enough to understand and implement. Even for validation, 
> providing the service number is hardly onerous, so I'm not convinced 
> that we need to create exceptions.
>