I'm OK with this except for one point below...
On 2007-02-23 09:38, Elwell, John wrote:
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.
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
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
