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:
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 :-)
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.
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?
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
