Re: [sipcore] More comments on location-conveyance-04

["Elwell, John" <[e-mail]>]

James,

Some further remarks below (rest removed): 

> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]] 
> Sent: 09 November 2010 08:03
> To: Elwell, John; [e-mail]
> Subject: Re: [sipcore] More comments on location-conveyance-04
> 
> John
> 
> Thanks for the review, you caught a lot of nits that were oversights 
> from the recent text cut-down.  I'll go through them as best 
> I can in-line
> 
> At 02:25 AM 11/5/2010, Elwell, John wrote:
> >1. General
> >This document seems to lack procedures sections for a UAC, a proxy 
> >and a UAS. Some of the procedures can be deduced from material in 
> >section 4 and elsewhere, but it is normal, for any SIP extension, to 
> >specify procedures for specific entities.
> 
> [jmp] this has been the normal format in the past, and was as well up 
> until the -02 of this SIPCORE doc, but changed with the massive text 
> cut-down in -03 due to at least two factors
> 
> - not simply having one operational behavior example (diagram) to 
> work from. You'll see that section 3 has 4 equally useful examples 
> that end up covering most, if not all, of this operational behavior 
> taken 1 example at a time instead of one SIP entity at a time.
> 
> - the second factor was my new co-author's bent on seriously reducing 
> the paraphrasing or what other RFCs have said, sometimes dangerously 
> so (i.e., by not exactly matching what was written in those 
> other RFCs).
[JRE] Section 3 comprises only examples. There is no normative language in section 3. In fact, as far as I can see, the only normative language is in section 4, with a couple of exceptions in sections 6 and 7. Section4 does not refer normatively to section 3 (and I don't think it should). What this means is that somebody implementing this just has to obey the MUSTs (and perhaps the SHOULDs) in section 4 (plus the couple in sections 6 and 7). So if there is anything we need a UAC, UAS or intermediary to do that is not specified in those sections, it most likely will not be done. If the group is happy that everything is covered in section 4 (+ section 6 and 7), then fine, but I am doubtful. It certainly doesn't follow conventional practice for SIP standards track RFCs.

<snip/>

> >18. Section 4.1:
> >"However, if a SIP intermediary were to add location, even if
> >    location was not previously present in a SIP request, that SIP
> >    intermediary is fully responsible for addressing the 
> concerns of any
> >    424 (Bad Location Information) SIP response it receives 
> about this
> >    location addition, and MUST NOT pass on (upstream) the 
> 424 response."
> >How does the SIP intermediary know that the 424 refers to the added 
> >location, as opposed to the original location? If I understand 
> >correctly, a Geolocation header field in a 424 response denotes a 
> >corrected location, rather than a location in error, so comparison 
> >of sent and received Geolocation header fields would not work.
> 
> [jmp] to quote Jon's response to me about this
> 
> [JFP] This is one of many tangles introduced by the multiple location 
> object problem. We could either: a) add tons of cruft to support 
> this, or, b) merely say this is another defect of the poor design of 
> sending multiple location objects. The implication of 424 is that the 
> recipient has not gotten the location they need. The guidance here is 
> mainly for a case where the UAC did not provide location itself.
[JRE] We at least need to say something about it.

<snip/>

> >20. Section 4.1:
> >"The following table extends the values in Tables 2 and 3 of RFC 3261
> >    [RFC3261]."
> >I thought there was an agreement in the WG not to maintain tables 2 
> >and 3 in RFC 3261.
> 
> [jmp] hmmm... missed that memo
[JRE] The rfc4244bis draft from sipcore is already in alignment with that decision, so it makes sense to apply it to location-conveyance too.

<snip/>

> >26. Section 4.3:
> >If the request contains more than one locationValue, can there be 
> >more than one Geolocation-Error header field in the response, if 
> >more than one location is in error? However, my earlier comment 
> >about associating a Geolocation-Error with a particular 
> >locationValue would still be an issue.
> 
> [jmp] this really gets sticky, because as I see it, this means there 
> needs to be a inserter= and an inserted-by= entities introduced 
> (taken out in -03), which creates a whole lot of cruft that really 
> makes this doc just hard to handle.
[JRE] As I said above, we at least need to say something about this.

<snip/>

> >31. Section 4.3:
> >"If the LS wants this message
> >    processed without this permission reset, it MUST choose another
> >    logical path  (if one exists)." (two instances)
> >What is meant by "another logical path"?
> 
> [jmp] one that avoids this SIP server or chain of servers - because, 
> if the permission isn't reset, it'll be matched with a failure 
> repeatedly, right?
[JRE] But how does the LS choose another path? And do we mean UAC rather than LS?

<snip/>

> >35. Section 5.1:
> >"the SIP request uses a sips-URI [RFC3261]"
> >Would RFC 5630 be a more appropriate reference?
> 
> [jmp] neither Jon nor I think so
[JRE] I can don't mind either way - was just asking the question.

<snip/>

John