Subject: RE: [Ecrit] LoST comment: Client request for region data

From: "Hearty, John" <[email-masked]>
Date: Mon, 13 Mar 2006 12:01:45 -0700

Good point.  What if the jurisdiction policy is to not include the
region?  Then nomadic devices can't count on data when they move, and
would either have to 1) send new queries each time they attach to a new
AP, or 2) rely on a query when an emergency call is made.  Option 1
might put undue load on the location servers.  I believe there has been
discussion on this list that option 2 may be bad.

If including the region in responses was made mandatory these issues
would go away.  It also addresses your very valid concern by reducing
complexity of what might be included in a response based on jurisdiction
policy.

John

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, March 13, 2006 11:31 AM
> To: Hearty, John
> Cc: [email-masked]
> Subject: Re: [Ecrit] LoST comment: Client request for region data
> 
> John,
> 
> that's probably a good idea, but I'm in general concerned about
> complexity. The more options, the more code complexity and the more
> options to test. Besides a few extra bytes, there's no harm in
> transmitting the information. Non-nomadic devices are likely to
provide
> civic address information; region information for this is likely to be
> as short as a partial PIDF civic address description, such as a town
> name or street address. In all likelihood, we'd be talking about fewer
> than 100 extra bytes here. I'd imagine that for most non-nomadic
> devices, getting a 100 bytes extra per day isn't going to make all
that
> much difference.
> 
> Henning
> 
> Hearty, John wrote:
> > Section 3 says:
> >
> >
> >
> > Depending on the query, the result may contain a region where the
same
> > mapping would apply...  The combination of these components are left
to
> > the needs and policy of the jurisdiction where the server is being
> operated.
> >
> >
> >
> > It might be a good idea for the client to ask for the region in its
> > query rather than (or in addition to) leaving it up to jurisdiction
> > policy.  For example, nomadic devices might be very interested in
region
> > information per point 2 that follows the above text.  However,
> > non-nomadic devices may not care about region information.
> >
> >
> >
> > John Hearty
> >
> > Level3 Communications
> >
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Mar 2006 14:13:10 -0500

I generally agree with your sentiment. In my opinion, having SHOULDs and 
"policy" in protocol specs are generally recipes for interoperability 
problems and excuses for implementor/contractor/supplier laziness. They 
are sometimes necessary, but MUST be used sparingly.

It sounds harmless to say "local policy", but we should be very careful 
that we don't sound neutral on something we believe to be generally a 
bad idea. Not all operators fully understand the consequences of 
low-level design decisions, particularly if they buy off-the-shelf software.

In this case, I believe the right answer is 'MUST implement' and 'MUST 
use for geo' (since the UA has no idea when to requery otherwise and can 
only guess wrong) and possibly a 'MAY use for civic' (since the use of 
regions is likely to be of less value for devices that query in civic, 
i.e., hot spots and landline).

Clearly, you don't have to provide the exact boundary of your 
jurisdiction, as an approximation will do in some cases.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 15 Mar 2006 20:30:24 -0500

On Mar 13, 2006, at 2:13 PM, Henning Schulzrinne wrote:

> I generally agree with your sentiment. In my opinion, having  
> SHOULDs and "policy" in protocol specs are generally recipes for  
> interoperability problems and excuses for implementor/contractor/ 
> supplier laziness. They are sometimes necessary, but MUST be used  
> sparingly.

Having clients depend on expectations that some server operators will  
not be able to meet due to policy reasons is an even bigger recipe  
for disaster.  Just because we may not agree with such policies  
doesn't mean that some jurisdictions and some server operators will  
not have to abide by them.  So servers SHOULD send the region data  
(in the true sense that SHOULD means if you do not you ought to know  
the consequences) and clients MUST be prepared to accept responses  
without region data.  The last thing we want is a server pushing crap  
data across an inflexible protocol.

With regard to complexity over a "I don't care for region data" flag,  
I think we have seriously bungled the problem from the start if such  
a simple thing adds just enough more complexity to make this thing  
hopeless.  It's a boolean flag that short circuits a possibly complex  
lookup and bigger payload.  Vendors who find it too complex ought not  
be distributing software.

-andy