Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jun 2006 19:10:49 +0000

New submission from Hannes Tschofenig <[email-masked]>:

Hannes wrote: 

* Henning suggested to extend LoST to return additional information regarding 
the service (e.g., location information needed). This discussion is relevant 
for LoST. I can see that there was support for his proposal. This aspect does 
not need to be captured in the requirements draft. 

Here is Henning's proposal: 

"
One pretty simple solution is to have a four-valued attribute:

- required --> no service without it; you're legally obligated to  provide it 
for this service
- helpful  --> the receiver would like to have this information, but  isn't 
going to refuse the call and you're not legally obligated; if  you route the 
call yourself, you don't need to include it in signaling
- routing  --> the receiver doesn't need it, but it's used to route  the call
- ignored  --> the receiver will just ignore the location information  and 
there's no location-based routing

I suspect this can be split into two dimensions (routing and end  system). 
"

Question: Is this something to consider? 
(PS: I might have missed other, much better, proposals in the mailing list 
discussion.)

----------
assignedto: hannes
messages: 10
nosy: ecrit, hannes
priority: critical
status: unread
title: Adding Additional Info to LoST Response

__________________________________________________
LoST Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/lost/issue7>
__________________________________________________

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 5 Jun 2006 19:40:30 -0500

Keep in mind that for our primary use case, this information is already known.  I'd consider it likely that clients will also know the answer for a other services.  No guarantees, so it could be useful.

We have to be careful about adding too much to the core protocol.  Like the list services, I think that this is something that can be added later, as an extension.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, 6 June 2006 5:11 AM
> To: [email-masked]
> Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response
> 
> 
> <http://www.tschofenig.com:8080/lost/issue7>

------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Jun 2006 20:46:11 -0400

We went through this before, where we discussed that these  
requirements may well depend on the country you happen to be asking  
about and are thus unlikely to be known by the client, at least not  
without manual configuration (which we are presumably trying to avoid).

On Jun 5, 2006, at 8:40 PM, Thomson, Martin wrote:

> Keep in mind that for our primary use case, this information is  
> already known.  I'd consider it likely that clients will also know  
> the answer for a other services.  No guarantees, so it could be  
> useful.
>
> We have to be careful about adding too much to the core protocol.   
> Like the list services, I think that this is something that can be  
> added later, as an extension.
>
>> for LoST. I can see that there was support for his proposal. This  
>> aspect
>> does
>> - required --> no service without it; you're legally obligated to   
>> provide
>> it
>> for this service
>> going to refuse the call and you're not legally obligated; if  you  
>> route
>> the
>> - routing  --> the receiver doesn't need it, but it's used to  
>> route  the
>> call
> [mf2]_______________________________________________
> Ecrit mailing list
> [email-masked]