Brian, Thanks for your guidance. See my further proposals below.
John > -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: 23 February 2007 07:50 > To: Cullen Jennings; Elwell, John > Cc: Sharon Chisholm; [email protected]; Keith Drage; Dean Willis > Subject: Re: [Gen-art] Gen-art review of > draft-ietf-sip-connected-identity-04.txt > > On 2007-02-23 01:02, Cullen Jennings wrote: > > > Brian, could you do me a favor and have a look at these and > if you think any of them need to be DISCUSS, let me know and > I will try and deal with DISCUSS level issues quickly. This > is an important draft that I want to move along as fast as possible. > > There are a few of Sharon's points that look like necessary > clarifications to me. I wonder whether a new draft in the > next day or two won't be simplest. Below: [JRE] I could certainly provide a new draft in the next day or to if requested to do so. > > On 2007-02-21 19:14, Elwell, John wrote: > > >> 6. In section 3, fifth paragraph, has the sentence 'It is > assumed that > >> deployed proxies will already be able to tolerate a change > of URI, since > >> this has been expected for a considerable time.' which > doesn't sound > >> like a standards-track RFC to me. A number of the > sentences that follow > >> in this section are also a bit loose. > > > > [JRE] Standards track RFCs do not need to contain only > normative statements > > and, I believe, can give reasons for things. I guess I > could make this > > particular sentence a note, but in view of your comment > above about notes I > > await your feedback. Or is it just the clause "since this > has been expected > > for a considerable time", which I guess could be deleted if > that would help. > > But this paragraph doesn't seem to completely tell me what > to code. I agree with Sharon that the language needs to be more > prescriptive, even if it's not normative. Tell the programmer > what to do :-) [JRE] So I propose to write instead "This document makes no provision for proxies that are unable to tolerate a change of URI, since changing the URI has been expected for a considerable time." Would this help? > > >> 11. In section 4.4.2, second paragraph, it says "if the UA > >> sends a 2xx > >> response", but what if it doesn't? Are there no expectations then? > > > > [JRE] Good catch. I have added "If any other final response > is sent the UA > > MUST NOT update the remote URI for this dialog." > > Yes, this is needed. > > > > > 12. In section 4.4.5, second paragraph, > > Actually s 4.5 > > >> "Note that when UAs conform with > >> this specification the Authentication Service will > normally be able to > >> authenticate the sender of a request as being the entity > identified in > >> the From header field and hence will be able provide a > signature for > >> this identity.". It wasn't clear whether this was defining > a requirement > >> or making a prediction about what other features might be > supported by > >> the implementation. > > > > [JRE] It is just making a prediction (since if the UA does > not conform to > > this specification the Authentication Service will not in > general be able to > > perform this authentication). It is not clear what change, > if any, I should > > make. > > I'm worried by the "normally". What's the abnormal case? Does > it matter? If you can resolve that, I think it will be OK. [JRE] What if I change "will normally" to "should (subject to the normal rules for authentication)"? So it would read "Note that when UAs conform with this specification the Authentication Service should (subject to the normal rules for authentication) be able to authenticate the sender of a request as being the entity identified in the From header field and hence will be able provide a signature for this identity." > > >> > >> 13. In section 4.7, the proxy itself advertises the > from-change feature? > >> If so, this could be stated more clearly and earlier in > the section. The > >> second paragraph is not parsable. > > > > [JRE] No, there is not intention to state that the proxy > advertises this > > feature. Perhaps I should change the last bit to say > "Supported: from-change > > is indicated in the received dialog forming request." Does > the addition of > > the word "received" help? > > I agree with Sharon. The second paragraph just doesn't make > sense to me. Who is sending 'Supported: from-change' to who? [JRE] Does my proposal above help. The resulting text would be "A proxy that is able to provide an Authentication Service for mid-dialog requests MUST record route if Supported: from-change is indicated in the received dialog forming request." Sharon said she could not parse this paragraph, but I suspect this could be because of the expression "record route", which is a well-known expression in SIP. > > >> > >> 14. In section 6, all the instructions to IANA are > one-time. Should the > >> RFC editor then delete the section before publishing? > > IMHO, no, this should definitely be preserved for the record. > > Brian > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
