Subject: RE: [Gen-art] Gen-art review of draft-ietf-sip-connected-identity -04.txt

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Feb 2007 08:38:59 +0000

Brian,

Thanks for your guidance. See my further proposals below.

John 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: 23 February 2007 07:50
> To: Cullen Jennings; Elwell, John
> Cc: Sharon Chisholm; [email-masked]; 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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Feb 2007 10:35:23 +0100

I'm OK with this except for one point below...

> because of the expression "record route", which is a well-known expression

Well, we are certainly penalised in this case by the lack of fonts in RFCs,
since putting terms like 'Supported: from-change' in italics would make
this a lot easier to read. I would prefer if you also stated where the request
comes from (it's presumably the SIP client, but since a proxy has two sides,
that isn't obvious to this reader). Thus
"...if Supported: from-change is indicated in the dialog
forming request received by the proxy from ???."

Thanks
     Brian