Re: [sipcore] location-conveyance-03 just submitted

["Thomson, Martin" <[e-mail]>]

Snipping stuff that I think we've resolved.

> >    A SIP intermediary MAY add a Geolocation header field if one is
> not
> >    present - for example, when a user agent does not support the
> >    Geolocation mechanism but their outbound proxy does and knows
> their
> >    Location...
> 
> This text is actually new, though the meaning was
> present in previous versions. What this means is
> that if a SIP request does not have a Geolocation
> header value, one *MAY* (i.e., more like _can_,
> but not all the way) be added by a SIP
> intermediary (i.e., proxy, b2bua, sbc,
> etc).  This last description is important -- as
> proxies cannot legally (per any RFC)
> add/modify/delete a MIME part (part), a b2bua or
> sbc can.  Many enterprise SIP systems are built
> around b2buas as their call servers - expressly
> for this capability (and for many other reasons
> too). This document isn't advocating or
> recommending intermediaries insert a Geolocation
> header value when one is not present in a
> received SIP request, but this doc makes it possible, that's all.

That's a good explanation, but I didn't get this from the text.  I think that perhaps all this needs is a little clarification: "A SIP intermediary *that acts as a B2BUA* MAY add a...".  I think that in this case, you would have to explicitly exclude "proxy" from the definition.

> >The composition scenario is a valid one, but it
> >still has the inherent limitations of location
> >by value - you can't get updates.
> 
> correct, not without possessing a location URI of
> the Target. But, that's what the geopriv-filters
> ID is for, defining how to subscribe to a Target
> (or its compositor server) to ask for current location of the Target.

Filters isn't really the definitive reference for that.  You might actually consider RFC 3856 to be the definitive reference (maybe referencing RFC 4079).
 
> >The use case is basically: route based on the
> >value, but provide a reference so that a PSAP
> >can get better location information later; that
> >is, updated or more accurate location.  That's
> >not possible if the UAC does the dereference:
> >the location information becomes fixed.
> 
> "...UAC does the dereference"? Do you mean to
> understand that the UAC inserts location towards
> an intermediary, gets a rejection 424, with the
> intermediary's version of where the UAC is -
> possibly as a location URI, and has to
> dereference that URI to compose the now dual location MIME body?

No - I'm saying that my major issue is driven by that use case.  There is (currently) no way for any entity (UAC or intermediary) to insert both location by value and location by reference.  There is a need for that capability.

> We mean to have the intermediary do the
> dereference (if one is needed) and compose in the
> SIP 424 response a MIME body with both the
> server's version or both locations of the Target,
> and for that dual location single presence
> document to be copied into the next SIP request
> from that UAC (towards that same intermediary).

Elegant as it is, this just doesn't work.  The UAS (PSAP, LR, etc...) needs to be the entity that does the dereference.  They need to do this because they know how (and when) to make this request so that they get the information they need.  If the intermediary does the dereference, then location information is set in stone from that point onward.
 
> Also, we do a little dance around idea - in text
> - the concept of us not expecting the
> intermediary receiving a 911 or 112 style
> emergency call from ever returning a 424
> rejection. We say we expect, but can't say this
> normatively, that the intermediary will become a
> b2bua for that call setup and compose (or
> overwrite) the location in the SIP request and
> forward that towards a PSAP/emergency call center.

BTW, I liked that dance.  It's another win for pragmatism over dogmatism.

> I think this is inconsistent with the phonebcp, which will need to be
> fixed.

I'm still reading phone-bcp against previous versions.  I'll await a phone-bcp update and we can discuss how the two interact then.

> >There are multiple ways to address this
> >problem.  One idea - that may be a bad one, I
> >don't know yet - is to add a reference to a
> >Content-Location header in combination with the
> >PIDF-LO value.  The other was to add PIDF extensions for indirection.
> 
> I don't know what a "Content-Location" header is,
> but given that Jon created the PIDF-LO, and was
> instrumental in this Conveyance rewrite, he's
> proposing the above be the solution.

As I stated, I don't see that there is a solution yet.

> >I understand, my concern was that the
> >description of the classes didn't make it
> >sufficiently clear that each of the 1xx, 2xx and
> >4xx classes had a single error code in them.
> 
> oh... yeah, I think I agree (even without looking
> back at it). That's been at the back of my mind
> since Jon whacked another section that I wrote in
> an early version of this -03. I was meaning to
> get back to that.  I'll make it clear that each
> are classes, where each x00 error code has a text
> string that's clearly understood (similar to
> what's there in the IANA section now). I'll make
> it clearer that how more error codes can be added to each category too.

Great.  But please tell me that you aren't fixing the error text to the error code.
 

> Two of us felt it important that there be an
> example of a composed single MIME body for some
> readers.  Are you suggesting, that you feel the
> composed dual value body is of less value than one value and one
> reference?

That's based on what I know we need - I don't have a strong need for composition right now.  Of course, everyone is allowed to have their own perspective on this sort of thing.

Cheers,
Martin