Hi, On Tue, Apr 8, 2008 at 7:48 PM, Hadriel Kaplan <[EMAIL PROTECTED]> wrote: > > > 2) If a Register is 3xx redirected, does the new retargeted Register > > use the same reg-id, even though it's a different "flow"? (I assume so) I > > ask because some people use 3xx for Registers to load-balance or perform > > anycasting. It may be good to add this to end of section 4.2.1. > > > > Yes, the UA uses the same reg-id. It uses the the reg-id to indicate > > that this is (for example) my "2nd logical flow" to my registrar or > > the logical flow over my "cellular interface". Can you suggest > > something here or point out the specific part that is confusing.? > > I ask because one could get a 3xx for Register at any time, for example > while there is an established dialog over that flow. (but it would be weird, > and we can't account for all bizarre corner cases) > At the end of section 4.2.1, add: > "If the registering UA receives a 3xx response to the REGISTER request, such > that it moves its registration "flow", it SHOULD reuse the same reg-id value > for the moved REGISTER."
I think it may already say to do something like that overall in another place. I'll take a closer look and see if it adds or detracts from the overall clarity of the document. > > > 6) Page 12, Section 4.1: > > > "It also provides an easy way to guarantee uniqueness within the AOR." > > I'm a bit confused by that, because I don't believe we're saying one UA > > instance only ever represents one AoR. (ie, multiple AoR's registered on > > the same UA will have the same registered contact instance) Recommend > > removing or rewording. > > > > I don't see the confusion. _Within_ the AOR, the instance-id provides > > further disambiguation. I can absolutely use the instance with more > > than one AOR. > > Ahh, then maybe it's a missing comma that screwed me up. Should be: > "It also provides an easy way to guarantee uniqueness, within the AoR, when > multiple UA's are registered for the same AOR." > Otherwise to me it looked like it was claiming the instance guaranteed > uniqueness [to] the AoR. I think this is more confusing with the extra commas, and the RFC editor is likely to just remove them anyway. (I remember paragraph upon paragraph in the Replaces or MWI spec where the only change between the RFC and the approved ID where a bunch of commas removed.) > > > 9) Page 16, Section 4.3: > > > ... For TLS protocols, there MUST also > > > be a match between the host production in the next hop and one of the > > > URIs contained in the subjectAltName in the peer certificate. > > > s/production in/resolved for/ > > > > I don't think your proposed rewording is correct. Perhaps s/next > > hop/next hop URI/ ? Actually when I looked at the text again, it is completely wrong. If the certificate has a domain name in subjectName, but no subjectAltName, the UA should compare against that too. > OK. Is "production" a common use for it? Maybe s/production in/portion of/ > as well as your URI addition? Yes. FYI: "production" has a very specific meaning. It refers to a name used inside the BNF. The host production in the RFC 3261 is shown here: SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] ... hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference thanks, -rohan _______________________________________________ Sip mailing list https://www.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
