Subject: [Ecrit] Allowing a full LoST response in the Held Routing response

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 24 Mar 2015 21:38:43 +0000

As I stated in IETF 92, I believe the IETF should allow all the possible values in a LoST response to be returned from a HELD response in situations where a single query is needed or desirable.  As an example, the service boundary may be useful for mobile devices, the service number is very useful, and

I further take exception to the notion that the mapping response in a restricted use case would necessarily be difficult or involve misleading data.  The example given is the “source” parameter.  In the cited use case, the HELD server is the authoritative source of the response, and it’s URI is a very appropriate value for source.  If it really only has one value, the “sourceId” could be a fixed, short string.

I would like to suggest that the text be reworded so the LoST <mapping> response is used instead of <routingInformation> and to be something like:

This document imports the <mapping> schema from RFC5222 as the response from the HELD routing query.   Where the HELD server is not consulting any other service for the routing data, it would use it’s own URI for the “source” function.  Many of the <mapping> elements are optional and while they may not be seen in many implementations of HELD routing, they have some value in other deployments.

Brian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 24 Mar 2015 21:56:45 +0000

One problem I am having with your argument is that I read RFC 5985 as providing a protocol between a client and a service which is a LIS. I do not see anything that says the major application supported on that protocol is Lost, whereas your argument seems to be that all applications on that protocol need to support Lost.

Can you point me to something that supports your viewpoint.

regards

Keith

________________________________
From: Ecrit [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: 24 March 2015 21:39
To: James Winterbottom
Cc: [email-masked]
Subject: [Ecrit] Allowing a full LoST response in the Held Routing response

I further take exception to the notion that the mapping response in a restricted use case would necessarily be difficult or involve misleading data.  The example given is the "source" parameter.  In the cited use case, the HELD server is the authoritative source of the response, and it's URI is a very appropriate value for source.  If it really only has one value, the "sourceId" could be a fixed, short string.

This document imports the <mapping> schema from RFC5222 as the response from the HELD routing query.   Where the HELD server is not consulting any other service for the routing data, it would use it's own URI for the "source" function.  Many of the <mapping> elements are optional and while they may not be seen in many implementations of HELD routing, they have some value in other deployments.

Brian

---

From: <[email-masked]>
Date: Tue, 24 Mar 2015 22:58:46 +0100

Hi Keith,
thank you for pointing to this. I support your view.
I'm happy to go with the draft as it is.

Regards

Roland

Von: Ecrit [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Dienstag, 24. März 2015 22:57
An: Rosen, Brian; James Winterbottom
Cc: [email-masked]
Betreff: Re: [Ecrit] Allowing a full LoST response in the Held Routing response

regards

Keith

Cc: [email-masked]<mailto:[email-masked]>

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 24 Mar 2015 22:06:13 +0000

I’m not suggesting that there is a LoST server in this architecture.  I’m suggesting that the HELD server that is returning the routing information should be able to return everything that a LoST server could return.

Brian

From: <DRAGE>, "Keith (Keith)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 24, 2015 at 4:56 PM
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>, James Winterbottom <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Allowing a full LoST response in the Held Routing response

regards

Keith

Brian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 24 Mar 2015 22:10:03 +0000

OK, so lets ask the question a different way.

Why should an extension to an extendible protocol cover what should be allowed to be sent in relation to other extensions. Surely anything that the IETF wanted in that respect should have been covered in RFC 5985 itself.

Keith

________________________________
From: Rosen, Brian [mailto:[email-masked]]
Sent: 24 March 2015 22:06
To: DRAGE, Keith (Keith); James Winterbottom
Cc: [email-masked]
Subject: Re: Allowing a full LoST response in the Held Routing response

I'm not suggesting that there is a LoST server in this architecture.  I'm suggesting that the HELD server that is returning the routing information should be able to return everything that a LoST server could return.

Brian

regards

Keith

Brian

---

From: James Winterbottom <[email-masked]>
Date: Wed, 25 Mar 2015 09:12:53 +1100

I don't understand why simply adding an extension point to the sequence in the server element won't address your requirement Brian.

Then if you want to return the stuff you can, but applications that don't want or need it don't have to be concerned with it.

Cheers
James

Sent from my iPhone

> On 25 Mar 2015, at 9:10 am, "DRAGE, Keith (Keith)" <[email-masked]> wrote:
> 
> From: <DRAGE>, "Keith (Keith)" <[email-masked]>
> To: Brian Rosen <[email-masked]>, James Winterbottom <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 24 Mar 2015 22:16:22 +0000

The document at issue is an extension.  It’s providing something other than location.  It is beyond what the working group considered when HELD was defined.

The LoST response was carefully considered by the working group and contains several items thought to be useful to an entity querying for routing of an emergency call.  I think that consideration applies fully to the present extension to HELD.
There is no fundamental difference to extending HELD to include a route than extending it to return an expiration for that route (HELD could be invoked before a call, for example), or, more specifically, for a service number.

Brian

Date: Tuesday, March 24, 2015 at 5:10 PM

Keith

Brian

regards

Keith

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 24 Mar 2015 22:19:42 +0000

Because we have already defined an appropriate response to a request for emergency call route, and I think requiring someone to come back later and add stuff we already believe is useful is bad protocol design.  Do it right the first time.
We thought about this stuff, we decided what we thought was useful.  I think having this alternative way to get a route doesn’t change what is in the response, in the same way that the form of location is the same regardless of whether we use SIP Presence or HELD to get it.  This is a emergency call routing response, we have one, re-use it.

Brian

From: James Winterbottom <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 24, 2015 at 5:12 PM
To: "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>>
Cc: Brian Rosen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Allowing a full LoST response in the Held Routing response

Cheers
James

Sent from my iPhone

On 25 Mar 2015, at 9:10 am, "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>> wrote:

Keith

Brian

regards

Keith

Brian

---

From: James Winterbottom <[email-masked]>
Date: Wed, 25 Mar 2015 10:53:31 +1100

I don't think that the use case in question has that requirement as the data is not likely to be sourced in the manner that LoST assumes. This makes the LoST data the exception not the rule. In XML we handle this kind of exception via extensions that come later as the need arises.

Cheers
James

Sent from my iPhone

> On 25 Mar 2015, at 9:19 am, "Rosen, Brian" <[email-masked]> wrote:
> 
> From: James Winterbottom <[email-masked]>
> To: "DRAGE, Keith (Keith)" <[email-masked]>
> Cc: Brian Rosen <[email-masked]>, "[email-masked]" <[email-masked]>