Scott, (Shortened in places)
> -----Original Message----- > From: Scott Lawrence [mailto:[email protected]] > Sent: 28 April 2010 16:53 > To: Elwell, John > Cc: Scott Lawrence; [email protected] > Subject: Re: [BLISS] Review of draft-ietf-bliss-ach-analysis-06.txt > > On Fri, 2010-03-19 at 19:40 +0100, Elwell, John wrote: > > > Thanks for your review. Responses below. > > > > > While many readers may believe that they understand > what HERFP is, I > > > don't think it's appropriate to either assume that they > all believe > > > the same thing, or leave the uninitiated in the dark. I suggest > > > either finding an existing description appropriate to reference, > > > adding an appendix to include one, or replacing this > shortcut with > > > some short description of what happens. > > > [JRE] Added a short description: "HERFP is where different forked-to > > UASs return different error responses, yet in accordance > with RFC 3261 > > rules for forking proxies, only one of these reaches the > UAC. Thus an > > error response of possible significance may not reach the UAC." > > That's what I had in mind - a wording suggestion: > > 'HERFP' is shorthand for a common problem with error responses > to requests forked at a proxy; if multiple UAs return error > responses to such a request, RFC 3261 requires that the proxy > forward only one error response to the UAC. Thus an error > response of possible significance may not reach the UAC. [JRE] OK, I will adopt these words. > > > > Section 7.1: > > > > > > I don't know that the two normative (MUST) statements > here actually > > > make any sense in practice, and in any event they are not very > > > specific. > > > [JRE] Perhaps SHOULD? But I don't like that. We are trying > to improve > > interoperability, and the conclusion was that by turning off ACH > > features at the UA, leaving it to the proxy, a certain class of > > interoperability problem can be avoided. > > > > What does a UA having 'all ACH features turned off' really mean? > > > Never return a 3xx response? Never return a 486 busy response? > > > Disable the 'Do Not Disturb' button? Don't give the > user the option > > > to reject a call? > > > [JRE] It means responding to indicate the state, and > leaving the proxy > > to determine any subsequent action. > > > > Similarly, what does it mean that a proxy must 'operate > when ACH is > > > provided by the registered UA'? That the proxy cannot > implement any > > > redirection or retargeting? If so, then the assertion that this > > > 'typically would be the default configuration' is > certainly not true > > > of any system I've encountered. > > > [JRE] Normally an out-of-the-box proxy has all ACH features turned > > off. It will need some configuration to cause forwarding > from A to B, > > for example, this can never be default. > > My real point is that I'm not sure that there is any value in making > statements about what is 'typically' true. Any system that includes a > voicemail service that I've ever seen includes sending calls to > voicemail by default when not answered. [JRE] I have deleted the bits about typically being the default configuration. > > I certainly agree that it should be possible to tell either a > proxy or a > UA not to do any redirection or retargeting... if you like MUST for > that, that's fine. > > > > Section 7.2 says: > > > > > > o Response code 487 for silent rejection/local. This > is the same > > > response code that would be used if a proxy were to > > > issue a CANCEL > > > request. > > > > > > That's a new (to me, at least) usage that does not seem > to me to be > > > within the meaning given to it by 3261: > > > > > > The request was terminated by a BYE or CANCEL request. > > > This response > > > is never returned for a CANCEL request itself. > > > [JRE] Exactly, if I send a CANCEL, the UA will respond to > the INVITE with 487. > > My reading of that suggestion was that if my phone rings, and I press > the 'reject silently' button on my phone, then it should send 487. I > don't think that's correct behavior because there was no > CANCEL from the > UAC. If that's not what you meant, then that section is confusing. [JRE] I have changed the wording to say: "This is the same response code that would be used to reject an INVITE request if a proxy were to issue a CANCEL request." [JRE] I would like to issue an -07, but prefer to wait until there has been some discussion on the thread I initiated on 15th April. John _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
