At 05:04 PM 4/25/2007, Henning Schulzrinne wrote:
On Apr 25, 2007, at 5:51 PM, James M. Polk wrote:
this is interesting, but we have to account for errors that
identify *what* was wrong in an LO (value or reference, assuming
the dereference worked), and that requires more header parameters -
thus making this header larger than this example. Do you think we
can merely list the CAtypes that were supplied that were good, and
list those that are still necessary by the Location Recipient? Or
just the ones still needed, with text stating to include all that
was in the original LO *and* "these" new ones?
I don't understand this comment. The information is pretty much
exactly what's in the current warning header.
for whatever reason, a request has a PIDF-LO with city, street,
street number, etc *but* not state or country. How does this get
indicated in the new Geolocation-Error header field format?
this is exactly the example that was given to me two IETFs ago when
you (and others) wanted the XML blob as a message body part in the
424 response (with the exact failure and the exact fields that are
bad (for whatever reason)).
I had no problem with goin along with that message body in 424 idea,
but I had a timing issue with "it ain't done yet, and it ain't even
started yet, so how long is it gonna take to get there" wondering.
I put it into -06 and got a few comments that absolutely didn't like
the idea, so I took it back out, leaving us with little exact info on
what's bad in the request that Warning (and Reason) can't solve for
in their current form.
However, I do see the need, if this new header progresses through
WG consensus as necessary, to extend the Geolocation header that's
currently in Conveyance to include this location "tag" header
parameter. I think they need to match up so the UAC understands
which location, if more than one is in a request (but not more than
one inserted by the UAC), the error is referring to.
Right.
Do others agree with this?
As much as I think this is an easy way of doing this, no vendor
that I know of that's doing the Resource-Priority header from RFC
4412, for example, is coding the Accept-Resource-Priority header -
also defined in 4412.
My guess is that 4412 is used within single domains, so there's
little doubt as to what namespaces are being supported.
but they aren't trustworthy domains, so the administrators don't want
to give someone the answer if they don't already have it
Is this a case where this one Accept-* is not being done? Or a case
in which most/any Accept-* aren't being done - so why do we keep
creating new ones?
They seem to be commonly used for other SIP-related things. At least
they show up on IMS call flows... Certainly beats creating a new
error code for each new URL scheme that comes along (which doesn't
convey the same information).
What do others think here?
Henning
_______________________________________________
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
