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

Robert Sparks <> Fri, 27 January 2012 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 025F321F86CF for <>; Fri, 27 Jan 2012 12:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.482
X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uonane-RtHOu for <>; Fri, 27 Jan 2012 12:49:18 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 33D9421F86CE for <>; Fri, 27 Jan 2012 12:49:18 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q0RKnFBg097372 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 14:49:16 -0600 (CST) (envelope-from
Message-ID: <>
Date: Fri, 27 Jan 2012 14:49:15 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Alan Johnston <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Subject: Re: [BLISS] AD review: draft-ietf-bliss-shared-appearances-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jan 2012 20:49:19 -0000

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 
up removed.  Can you summarize what the changes were that addressed it?

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

>>> 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 

>> 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 
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.

>>> 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?


(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).

>>> 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!