Subject: [Sip] Conveyance -08 and Geolocation-Error header

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 19:22:19 -0500

Henning

Regarding Conveyance -08 and the new Geolocation-Error header that 
you want to replace the Warning header code(s) function (section 3.4 
of the -07 ID)...

What fields do you want in the header?

#1 error-code,
#2 text-string explaining what error it is
#?

Do you need anything else?

Warning had/has the node ID of the sending entity. Do you want that 
in the new Geolocation-Error header?  Do you really see a purpose in 
having that piece there?

Attempting to put the final pieces of -08 together, and this new 
header is less than straightforward in writing it.

Is this viable ABNF for what you want?

Geolocation-Error  =  "Geolocation-Error" HCOLON (locationErrorValue
                         *(COMMA locationErrorValue))
locationErrorValue =  numeric-code *(SEMI geoloc-error-param)
numeric-code       =  decimal-string
geoloc-error-param =  "code" EQUAL error-text-string
                        / generic-param ; (from RFC 3261)
error-text-string  =  string

(anyone) let me know what you think

Thanks
James

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jul 2007 21:31:34 -0400

James,

I think your #1 and #2 covers it, in addition to an identifier that  
points to the location element that suffers from the problem  
identified. (The latter was discussed, if I recall correctly, but  
seems to be missing from your syntax proposal.)

I don't feel strongly about identifying the originator of the error,  
but it might be useful to have an extensible parameter list, in  
standard SIP header fashion, so that we can easily add more debugging  
information later.

Henning

On Jul 5, 2007, at 8:22 PM, James M. Polk wrote:

> you want to replace the Warning header code(s) function (section  
> 3.4 of the -07 ID)...
>
> in the new Geolocation-Error header?  Do you really see a purpose  
> in having that piece there?
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 20:45:36 -0500

>seems to be missing from your syntax proposal.)

this is the Warning header's nodeID part. I wanted to know if you 
wanted that to remain in this new header. I sounds like you do.

Question - what's the difference between "...he location element that 
suffers from the problem identified..." mentioned above and how you 
"... don't feel strongly about identifying the originator of the 
error". Aren't they the same node?

If not, I need to understand, as I define what ID goes into this header.

Another point - should this error header only be in the 424 (Bad 
Location Information) response, or all 4XX responses, allowing a 
transaction to be successful - but without the location piece of the 
information exchange being good?

This was discussed, but I don't think the discussion ever concluded.

>standard SIP header fashion, so that we can easily add more debugging

I agree with this last point. Do you want something more than the 
existing "generic-param (from RFC 3261)" I have there now?

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jul 2007 21:53:33 -0400

Let me try to explain:

Let's say proxy P1 inserts location information L1, and user agent U1  
inserts L2. I want to identity L1 and L2, not necessarily the IP  
addresses or host names for proxy P1 or user agent U1 (which may or  
may not be unique, if NATs are involved).

The reason is simple - some element may insert location information,  
and the poor sender will try to figure out an error for location  
information it has never inserted.

I think this should be in all responses, as calls may succeed even if  
the location information, or one piece of it, happens to be bad. I  
still want to know that the call may have been routed without taking  
the location information into consideration, say, and why.

The 3261 generic-param is fine with me.

Henning

On Jul 5, 2007, at 9:45 PM, James M. Polk wrote:

> Question - what's the difference between "...he location element  
> that suffers from the problem identified..." mentioned above and  
> how you "... don't feel strongly about identifying the originator  
> of the error". Aren't they the same node?
>
> transaction to be successful - but without the location piece of  
> the information exchange being good?
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 21:07:28 -0500

>may not be unique, if NATs are involved).

<light goes on>

this is important... many of us had realized this was a problem, I 
just didn't realize this new header solved it (yet).  It will now!

>I think this should be in all responses,

all?  even 5XXs and 6XXs?  I'm have a pragmatic attack thinking how 
in the world a UAS can process enough of a request to figure out 
location is bad, but still error the message because of something it 
can't do more fundamentally with the request outside of 
location.  There aren't that many 5XX and 6XX responses, so I'm not 
fighting it - just trying to understand what you want.

I'm open to all 4XX (cuz I can see this working in most 4XX responses 
(like a double error of "this *and* that" were wrong with this 
request), which is why I offered it (instead of limiting this to just the 424).

>as calls may succeed even if

good!

Thanks!

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jul 2007 22:14:41 -0400

> location is bad, but still error the message because of something  
> it can't do more fundamentally with the request outside of  

I'm not a friend of being overly prescriptive and trying to predict  
all cases, including future status codes. In most cases, inserting  
the information may not make sense, but it is always harmless, even  
if it goes along with a 5xx or 6xx response. After all, both types of  
errors may occur at the same time. If the location information is  
broken, I want to be told about it, regardless of what other problems  
the SIP request had. (Plus, the location error information may have  
been inserted along the way by a proxy trying to use it for location  
routing. The UAS getting the location error indication shouldn't just  
swallow this information - it's useful to the UAC.)

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 21:58:57 -0500

>swallow this information - it's useful to the UAC.)

fair -- the text is changed to allow it in all responses

New topic -- Do we want at all to try and tackle mapping of which 
location goes with which error, to make sure each receiver of the 
response pays attention or ignores what they are supposed to (wrt 
locationValues)?

If this is a good idea, would a header parameter sequence number 
(mapped between Geolocation header and Geolocation-Error header) do 
the trick? I think we'll just need to make sure the numbers don't 
replicate another sequence number within the same Call-ID, and not be 
universally unique through space and time.

This might be a little too much to take on this late (to the 
deadline) or it just might be too silly of an idea *or* do you think 
the host ID within the Geolocation-Error header might be enough to 
cover this idea.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jul 2007 23:06:09 -0400

> replicate another sequence number within the same Call-ID, and not  
> be universally unique through space and time.
>

Agreed.

> deadline) or it just might be too silly of an idea *or* do you  
> think the host ID within the Geolocation-Error header might be  
> enough to cover this idea.

I'm not sure what format the hostID has. If IP address, you could end  
up with two 192.168.0.1, from different hosts, which would be rather  
confusing.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 06 Jul 2007 01:21:59 -0500

>up with two 192.168.0.1, from different hosts, which would be rather

Conveyance -07 gave a Warning hostID of alice.example.com as the format.

I agree this shouldn't likely ever be an IP address - due to your 
exact example problem.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jul 2007 14:27:38 -0400

Hmm. I've been behind on reading. I was having a side conversation with 
James on this, and it looks like some of that would be worth sharing 
here. James was asking me for ideas of how to handle this "identifier".

The following is what I last sent to James:

Paul Kyzivat wrote:
> What do you expect will happen as a result of identifying the source of the error?
> 
> Do you expect that the source will itself recognize that it has made a mistake and do something about it? Or do you expect some other element to keep notes on which nodes do a bad job of supplying addresses?
> 
> Also, do you expect the node that inserts the address to remember what address it inserted when it gets the error response? Or some other node other than the one that inserted it to remember it?
> 
> The answer to these questions impacts the kind of solution that is appropriate.
> 
> If the UAS is the one to detect the problem, and also the one to log the problem for future use, then it must be possible to actually determine the address of the source of the address. An index into the Via list might be adequate for that. Or, the "inserted-by" could be changed to actually include the address of the node doing the insertion.
> 
> If the node doing the insertion is responsible for tracking its own failures, then its probably bad to assume that it will remember what it inserted. So the actual offending address should probably be included in the error response. In that case, there is probably something in that address that will allow the offender to recognize that it was the source of the problem.
> 
> If some other node (other than the UAS and the offending node) is responsible for logging the problem, then it will certainly want the offending address as well. So again it should be included in the response. And again, there probably isn't need of anything else.
> 
> At least that's my take based on what little info I have.

	Paul

Henning Schulzrinne wrote:
> points to the location element that suffers from the problem identified. 
> (The latter was discussed, if I recall correctly, but seems to be 
> missing from your syntax proposal.)
> 
> I don't feel strongly about identifying the originator of the error, but 
> it might be useful to have an extensible parameter list, in standard SIP 
> header fashion, so that we can easily add more debugging information later.
> 
> Henning
> 
>> Regarding Conveyance -08 and the new Geolocation-Error header that you 
>> want to replace the Warning header code(s) function (section 3.4 of 
>> the -07 ID)...
>>
>> Warning had/has the node ID of the sending entity. Do you want that in 
>> the new Geolocation-Error header?  Do you really see a purpose in 
>> having that piece there?
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 6 Jul 2007 21:34:01 -0400

My general take is that the source, on the return trip, should be  
able to identify location information it has inserted. Note that a  
single UA or proxy could theoretically insert two locations (e.g.,  
geo + civic) or reference and value, so some additional  
identification beyond the node may be necessary. If it weren't for  
various SBCs mucking with Via's, the Via solution sounds interesting,  
but maybe the simple host name is easiest.

The problem with the host name (or Via) is that the party discovering  
the error and the party inserting the location are generally *NOT*  
the same. The error is likely to be discovered far downstream, e.g.,  
by the UAS or the PSAP proxy. The UAS or PSAP proxy has no way to  
know what node inserted the location, since the Geolocation header  
field currently only says "endpoint" or "server".

Thus, another variation that allows host identification and avoids  
this problem:

<proposal>
Just define ;inserted-by to use the host name, and then use the same  
parameter in the error indication.
</proposal>

Henning

On Jul 6, 2007, at 2:27 PM, Paul Kyzivat wrote:

> Hmm. I've been behind on reading. I was having a side conversation  
> with James on this, and it looks like some of that would be worth  
> sharing here. James was asking me for ideas of how to handle this  
> "identifier".
>
>> Do you expect that the source will itself recognize that it has  
>> made a mistake and do something about it? Or do you expect some  
>> other element to keep notes on which nodes do a bad job of  
>> supplying addresses?
>> Also, do you expect the node that inserts the address to remember  
>> what address it inserted when it gets the error response? Or some  
>> other node other than the one that inserted it to remember it?
>> If the UAS is the one to detect the problem, and also the one to  
>> log the problem for future use, then it must be possible to  
>> actually determine the address of the source of the address. An  
>> index into the Via list might be adequate for that. Or, the  
>> "inserted-by" could be changed to actually include the address of  
>> the node doing the insertion.
>> If the node doing the insertion is responsible for tracking its  
>> own failures, then its probably bad to assume that it will  
>> remember what it inserted. So the actual offending address should  
>> probably be included in the error response. In that case, there is  
>> probably something in that address that will allow the offender to  
>> recognize that it was the source of the problem.
>> If some other node (other than the UAS and the offending node) is  
>> responsible for logging the problem, then it will certainly want  
>> the offending address as well. So again it should be included in  
>> the response. And again, there probably isn't need of anything else.
>> I think your #1 and #2 covers it, in addition to an identifier  
>> that points to the location element that suffers from the problem  
>> I don't feel strongly about identifying the originator of the  
>> error, but it might be useful to have an extensible parameter  
>> list, in standard SIP header fashion, so that we can easily add  
>> more debugging information later.
>> Henning
>>> Regarding Conveyance -08 and the new Geolocation-Error header  
>>> that you want to replace the Warning header code(s) function  
>>> (section 3.4 of the -07 ID)...
>>>
>>> Warning had/has the node ID of the sending entity. Do you want  
>>> that in the new Geolocation-Error header?  Do you really see a  
>>> purpose in having that piece there?
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jul 2007 23:24:58 -0400

I have no skin in this game, so take my comments with a grain of salt...

Is it really reasonable to expect a proxy that inserts a location to 
remember what location it inserted, in enough detail to diagnose why it 
might have been messed up? I presume it would have to reconstruct what 
the location would have been based in information in the response. It 
may not be possible to reconstruct the exact same value, because the UAC 
may have moved in the meantime. I guess the inserted location would have 
to be by reference, but the URL of the reference may itself not be 
easily reconstructed, and multiple queries of it may not return the same 
result.

IMO it would be much clearer to include the location itself in the 
response. And if the location had been passed by reference, it might be 
better to pass it by value in the response, so that there is no 
possibility of the value changing.

OTOH that might result in divulging the location to nodes upstream of 
the one that included it. If it was passed by reference then the node 
that had inserted it could remove the reference in the response. But if 
it is passed back by value that isn't allowed.

The alternative is that the proxy will have to retain the location until 
the completion of the transaction. Maybe that's ok, but if its only to 
diagnose an occasional glitch I get it doesn't get done.

	Paul

Henning Schulzrinne wrote:
> My general take is that the source, on the return trip, should be able 
> to identify location information it has inserted. Note that a single UA 
> or proxy could theoretically insert two locations (e.g., geo + civic) or 
> reference and value, so some additional identification beyond the node 
> may be necessary. If it weren't for various SBCs mucking with Via's, the 
> Via solution sounds interesting, but maybe the simple host name is easiest.
> 
> the error and the party inserting the location are generally *NOT* the 
> same. The error is likely to be discovered far downstream, e.g., by the 
> UAS or the PSAP proxy. The UAS or PSAP proxy has no way to know what 
> node inserted the location, since the Geolocation header field currently 
> only says "endpoint" or "server".
> 
> Thus, another variation that allows host identification and avoids this 
> problem:
> 
> <proposal>
>>> Do you expect that the source will itself recognize that it has made 
>>> a mistake and do something about it? Or do you expect some other 
>>> element to keep notes on which nodes do a bad job of supplying 
>>> addresses?
>>> If the UAS is the one to detect the problem, and also the one to log 
>>> the problem for future use, then it must be possible to actually 
>>> determine the address of the source of the address. An index into the 
>>> Via list might be adequate for that. Or, the "inserted-by" could be 
>>> changed to actually include the address of the node doing the insertion.
>>> If the node doing the insertion is responsible for tracking its own 
>>> failures, then its probably bad to assume that it will remember what 
>>> it inserted. So the actual offending address should probably be 
>>> included in the error response. In that case, there is probably 
>>> something in that address that will allow the offender to recognize 
>>> that it was the source of the problem.
>>> responsible for logging the problem, then it will certainly want the 
>>> offending address as well. So again it should be included in the 
>>> response. And again, there probably isn't need of anything else.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 7 Jul 2007 08:06:02 -0400

On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote:

> Is it really reasonable to expect a proxy that inserts a location  
> to remember what location it inserted, in enough detail to diagnose  
> why it might have been messed up? I presume it would have to  
> reconstruct what the location would have been based in information  
> in the response. It may not be possible to reconstruct the exact  
> same value, because the UAC may have moved in the meantime. I guess  
> the inserted location would have to be by reference, but the URL of  
> the reference may itself not be easily reconstructed, and multiple  
> queries of it may not return the same result.
>
> response. And if the location had been passed by reference, it  
> might be better to pass it by value in the response, so that there  
> is no possibility of the value changing.
>

I tend to agree that this would be better. The reference-to-value  
translation may not always be feasible: If a proxy inserts a location  
reference and a downstream proxy finds a problem, it can't insert a  
value (except by the data URL mechanism I have been mentioning...).

> OTOH that might result in divulging the location to nodes upstream  
> of the one that included it. If it was passed by reference then the  
> node that had inserted it could remove the reference in the  
> response. But if it is passed back by value that isn't allowed.
>
> The alternative is that the proxy will have to retain the location  
> until the completion of the transaction. Maybe that's ok, but if  
> its only to diagnose an occasional glitch I get it doesn't get done.

My assumption was that most locations will be inserted by the UAC  
rather than a proxy. In those cases, retaining the information is  
probably not a big deal, since the UAC will generally only have one.

In summary, I think returning as much information about the erroneous  
location information as possible seems best, i.e., both the location  
information and the party that inserted it. This avoids the "who the  
heck put that bogus location information in there?" problem.

In general, I think we have learned that we should help people with  
debugging distributed systems with distributed responsibility, as  
otherwise they'll either struggle or invent private mechanisms to  
include this information. (See SER for the the latter.)

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 07 Jul 2007 18:25:20 -0500

>parameter in the error indication.

wouldn't this run into the same SBCs & B2BUAs mucking it up problem, 
thereby making this unreliable? I mean there could easily be 
domain-of-host scrubbing going on at borders, to include this field.

I'm not sure either if PSAPs reeeeally care if location was inserted 
by a UAC or proxy along the way - they just want something.  It 
sounded good when I first came up with the idea, but it is also 
merely informative in nature, and has zero integrity.

Also, if I go with your proposal, which seems easy to add, what 
strength do I put on the location inserter putting this in?  It seems 
like it ought to be something like  "...MUST insert inserter's 
host-id/name header parameter in the locationValue".

Matching this host-id/name into the GeolocationError header's 
locationErrorValue within the response seems easy then.

BTW Paul - there are lots of GeolocationError codes of various 
flavors, depending on what was wrong with the location when it was discovered.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 7 Jul 2007 19:41:38 -0400

>
> wouldn't this run into the same SBCs & B2BUAs mucking it up  
> problem, thereby making this unreliable? I mean there could easily  
> be domain-of-host scrubbing going on at borders, to include this  
> field.
>

Sure - any information could be removed. It just seems less likely.

> I'm not sure either if PSAPs reeeeally care if location was  
> inserted by a UAC or proxy along the way - they just want  
> something.  It sounded good when I first came up with the idea, but  
> it is also merely informative in nature, and has zero integrity.

I agree that the PSAP doesn't care who inserted the information and  
there's really not much difference between one inserted by a proxy  
and the end system, as far as the PSAP is concerned. The only one  
that cares is probably the caller (UAC), mostly if things go wrong.  
It can be really frustrating if some crucial information is inserted  
by some proxy you can't see, and you have no idea who did it and thus  
don't know if you should talk to your local provider or some other  
party closer to the destination. I don't know whether this is a  
realistic issue, given that most location information will be  
inserted either by the UAC or the outbound proxy.

Thus, maybe it would be sufficient to make the suitable extensibility  
hooks in both the Geolocation header and the error indication so that  
these can be added later, if we can't agree quickly on a suitable  
format.

> strength do I put on the location inserter putting this in?  It  
> seems like it ought to be something like  "...MUST insert  
> inserter's host-id/name header parameter in the locationValue".
>

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 07 Jul 2007 19:47:42 -0500

>these can be added later, if we can't agree quickly on a suitable

as much as anything, I'm thinking of going with your proposal to 
change "inserted-by=endpoint or server" to "inserted-by=host-id/name" 
so that transaction statefulness of location insertion is easier to 
recognize in a response.

This would blow up the idea of indicating if a locationValue was 
inserted by a endpoint or server... that was my point.

It also gets us away from tracking a sequence number (of what 
length?) and having to nail down all the parameters of that new value 
- consensus might be in 2009 on this one with a number

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 11 Jul 2007 21:42:13 +0200

You wrote:

> In general, I think we have learned that we should help 
> people with debugging distributed systems with distributed 
> responsibility, as otherwise they'll either struggle or 
> invent private mechanisms to include this information. (See 
> SER for the the latter.) 

If we are not careful here we end up back in the issue of responses
being significantly larger than the request sent on a particular hop,
and therefore the old problem of what happens on UDP when this occurs.

Regards

Keith

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Saturday, July 07, 2007 1:06 PM
> To: Paul Kyzivat
> Cc: [email-masked]; James M. Polk
> Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header
> 
> 
> > remember what location it inserted, in enough detail to 
> diagnose why 
> > it might have been messed up? I presume it would have to 
> reconstruct 
> > what the location would have been based in information in the 
> > response. It may not be possible to reconstruct the exact 
> same value, 
> > because the UAC may have moved in the meantime. I guess the 
> inserted 
> > location would have to be by reference, but the URL of the 
> reference 
> > may itself not be easily reconstructed, and multiple 
> queries of it may 
> > response. And if the location had been passed by reference, 
> it might 
> > be better to pass it by value in the response, so that there is no 
> I tend to agree that this would be better. The 
> reference-to-value translation may not always be feasible: If 
> a proxy inserts a location reference and a downstream proxy 
> finds a problem, it can't insert a value (except by the data 
> URL mechanism I have been mentioning...).
> 
> 
> > that had inserted it could remove the reference in the 
> response. But 
> > if it is passed back by value that isn't allowed.
> >
> > until the completion of the transaction. Maybe that's ok, 
> but if its 
> > only to diagnose an occasional glitch I get it doesn't get done.
> 
> My assumption was that most locations will be inserted by the 
> UAC rather than a proxy. In those cases, retaining the 
> information is probably not a big deal, since the UAC will 
> generally only have one.
> 
> In summary, I think returning as much information about the 
> erroneous location information as possible seems best, i.e., 
> both the location information and the party that inserted it. 
> This avoids the "who the heck put that bogus location 
> information in there?" problem.
> 
> In general, I think we have learned that we should help 
> people with debugging distributed systems with distributed 
> responsibility, as otherwise they'll either struggle or 
> invent private mechanisms to include this information. (See 
> SER for the the latter.)
> 
> 
> >
> > 	Paul
> >
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Jul 2007 16:39:04 -0500

>and therefore the old problem of what happens on UDP when this occurs.

one crazy (or stupid?) idea is

- now that there is a more robust Geolocation-Error header in 
responses (verses a Reason or Warning header), a *(SEMI CAType) could 
be added to it to allow a Location Recipient to include each CAType 
it had a problem with or wasn't there that was considered necessary 
to use the location in the first place.  This idea doesn't include 
the element values, just the elements - which saves bytes, and 
doesn't reveal the element values either.  It also doesn't include a 
message body in the response.

I think this is more information than is presently there, making for 
better decisions by location inserters or for troubleshooting.  The 
only security risk I see with this is the listing of some of the 
CAtypes that were in the original request.  Presumably there were 
other elements in the request, so little (if anything) can be 
extracted from this knowledge if intercepted.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Jul 2007 20:33:17 -0400

This could be done, but requires a mapping from XML tags to CAtypes  
at the proxy, which seems somewhat unnatural. Generally speaking, it  
seems likely that only one or two tags contradict each other or are  
"wrong", so that the saving is likely to be rather modest,  
particularly given that many of the civic XML tags are only two or  
three characters long. Thus, you might realize a saving of one or two  
bytes in most cases.

My major concern is identifying the source of insertion of the LI.  
This would be a domain name, typically 50 bytes or so, so I don't  
think this is a major issue.

On Jul 11, 2007, at 5:39 PM, James M. Polk wrote:

> responses (verses a Reason or Warning header), a *(SEMI CAType)  
> could be added to it to allow a Location Recipient to include each  
> CAType it had a problem with or wasn't there that was considered  
> necessary to use the location in the first place.  This idea  
> doesn't include the element values, just the elements - which saves  
> bytes, and doesn't reveal the element values either.  It also  
> doesn't include a message body in the response.
>
> I think this is more information than is presently there, making  
> for better decisions by location inserters or for troubleshooting.   
> The only security risk I see with this is the listing of some of  
> the CAtypes that were in the original request.  Presumably there  
> were other elements in the request, so little (if anything) can be

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Jul 2007 20:02:55 -0500

>three characters long. Thus, you might realize a saving of one or two

but I was comparing the savings of having only one or two (as you 
said) "CAType=<blah>" added to the Geolocation-Error header verses 
having a full PIDF-LO added to a message body in the response. I 
think you'll agree that the size/bytes savings in comparison is 
substantial - and goes towards Keith's point of UDP.

This also is consistent with most folks thinking that location 
shouldn't be in a response.  I think this proposal can get us a long 
way towards what you want, without saying "you said you were at N 
Main St., which doesn't exist, instead of NW Main St, which does". 
The CAType for prefix street name would be what's included in the 
response, because it was the part of the civic location that was bad.