Re: [BLISS] AD review: draft-ietf-bliss-shared-appearances-06

[Robert Sparks <[e-mail]>]

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