At 07:33 PM 7/11/2007, Henning Schulzrinne wrote:
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.
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.
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:
At 02:42 PM 7/11/2007, DRAGE, Keith \(Keith\) wrote:
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.
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.
Regards
Keith
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 07, 2007 1:06 PM
> To: Paul Kyzivat
> Cc: [email protected]; James M. Polk
> Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header
>
>
> 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.
> >
> > 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.
> >
>
> 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.)
>
>
> >
> > Paul
> >
>
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
