Hi Alan -
Going through the threads leading to version -09 - there were some things
in this message that I'm not seeing an obvious resolution to. Can you
point to where
or how they were addressed?
(Trimming to the things that I think might still be outstanding)
On 3/2/11 12:11 PM, Alan Johnston wrote:
I am finally working on a revision to the document. See below for
comments on the minor issues. There hasn't been any comments on the
major issues (changing 409 with 400 and updating RFC 3261 and 4235).
Comments most welcome. I should have the changes described here done
in the next few days.
- Alan -
<big snip/>
Section 5.4 talks about proxies inserting an Alert-Info field. Section
11 talks about proxies inserting and removing them. Both of these sections
use non-normative terms. Where is the normative behavior for proxies
participating
in this feature defined? Also, for section 11. "If an Alert-Info is already
present,
the proxy either removes the Alert-Info if it is not trusted, or adds
the 'appearance' parameter to the Alert-Info header field."
It's not clear that RFC3261 allows a proxy to modify (in particular delete)
existing Alert-Info header fields.
You are correct that RFC 3261 does not explicitly allow this, although
every real system does so. I would prefer to update RFC 3261 to
explicitly allow proxies to apply trust domain rules in modifying and
deleting Alert-Info header fields and parameters. However, if this
causes trouble, we can remove it. I'm working on some text for this.
I'm not sure I follow what happened in the text around this. Section 11
ended
up removed. Can you summarize what the changes were that addressed it?
<snip>
Where is there a description of how the joined and replaced dialog xml elements
are compared - there's an opportunity for error in implementation if they get
the perspective of local and remote tag incorrect - where is the text that
describes
what to compare these against?
I'll look at Replaces and Join and add in similar text.
Did that happen? (It may have, but I'm not spotting it quickly).
<snip/>
Section 10.1 : Do you want to also call out authorizing publishes? Suggest
rephrasing to avoid using "the same".
Will do.
I think you adjusted the phrasing, bit did you talk about authorizing
publishes?
<snip/>
10.9 : Note that Bob's UA is configured not to, not that Bob chooses not
to have an appearance number. What normative texts suppresses the normal dialog
state change notifications at the end of the paragraph?
There is none. Probably these NOTIFYs would get sent, although they
are of no use to anyone.
You fixed the issues with the text around normal notifications, but it still
says Bob chooses not to have an appearance number. This is a nit, and I'm
not going to stick on it, but please look to make sure that's what you
really
mean to say. I think you mean the software in Bob's UA is programmed to
and that you don't mean to imply that Bob is going to have to punch a button
on the phone at this point in time to communicate a choice to the UA.
<snip/>
11 - What text precludes a UA from putting in its own appearance number?
Nothing, but this yet another case why a proxy must be able to
delete/modify Alert-Infos that are not correct or come from an
untrusted source.
There should be some discussion of this in the document somewhere - am I
overlooking it?
<snip/>
(There was a discussion about making it easier to use /= for future
extensions to the ABNF
for this parameter that I don't think resulted in a change, but I'll
come back to it later).
<snip/>
Section 12 - This MUST to authenticate with Digest or S/MIME is stronger
than the Replaces spec requires for a generic INVITE/Replaces - were you
intending to further restrict the admission policy for INVITES associated
with this extension?
No, I'll check the INVITE/Replaces security considerations and make it match.
What change resulted?
----
Thanks for helping me check these!
RjS
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
