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

Alan Johnston <> Fri, 17 December 2010 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DE653A6900 for <>; Fri, 17 Dec 2010 08:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.452
X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YdaiXQ2idnWD for <>; Fri, 17 Dec 2010 08:16:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D414D3A68DE for <>; Fri, 17 Dec 2010 08:16:12 -0800 (PST)
Received: by bwg12 with SMTP id 12so1067045bwg.37 for <>; Fri, 17 Dec 2010 08:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9eb8DEvaDA8XdlS62REYi2l9370YbayadMyt8jUgoUg=; b=MYefdXiiCF7ifDaQBYqcWnBM1sptfHF+U1C2aEhIXwfXSUoC1Wkc6NnZiEqRGVnufV NxsXvYjevw9AZI1GyrNUK+UQMtzoS4B4qh0A4kWt0spnx2uC709TBBwTt1F4cg2iwOWU TtAxDMeVJVEhQZAxFfxR8mvtg8w31kVCR3uAQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ceP+0PxbP/s+IXvAcB41M0Gocy/PHVbQqPqlTOjEoINwaqNeHsCSTMx06G5XUlaq85 QKvRRvwa5rHMWYzaTjHiyxzC71tfOvFtCLZWnpQ2VONAXM71gYlgzv1ui2JTbXnIuOBt U9uXH5wnAnvFZcO2U9jwB88TyKDz8fJ5kf+xs=
MIME-Version: 1.0
Received: by with SMTP id o2mr797344bkc.210.1292602679192; Fri, 17 Dec 2010 08:17:59 -0800 (PST)
Received: by with HTTP; Fri, 17 Dec 2010 08:17:59 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 17 Dec 2010 10:17:59 -0600
Message-ID: <>
From: Alan Johnston <>
To: Robert Sparks <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [BLISS] AD review: draft-ietf-bliss-shared-appearances-06
X-Mailman-Version: 2.1.9
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, 17 Dec 2010 16:16:15 -0000


Thanks for your review of this document.  I plan to address all of
your comments in a revision early in January.  For now, I will reply
to your three major issues below and see if we can get working group
consensus on the resolutions.

- Alan -

On Mon, Dec 6, 2010 at 1:58 PM, Robert Sparks <> wrote:
> Summary: There are a few major issues that need to be addressed before progressing this document.
> Major Issues:
> 1) 409 is not a defined response code. Probably easiest to choose another.

I knew 409 was deprecated as a response to REGISTER, but I hadn't
realized we had deprecated the entire response code!

I suggest we just use a 400 response.  We had discussed including a
Retry-After header field with a very short value, or even zero, but
now I'm thinking about just omitting the Retry-After.

> 2) Is this an update to 3261 (through adding a parameter to Alert-Info)?

I am OK with this.

> 3) Is this an update to 4235 (through adding the shared parameter)?

I am OK with this.  We also make recommendations about dialog package
notifications that is stronger than RFC 4235, so this makes sense.

> ----
> Section 4.2 calls out "An analysis of other mechanisms has been performed".
> Has that analysis been captured?
> The list of steps in 4.2 is intended to be illustrative (I think). Can
> text be added to reinforce that this is not defining behavior. It might
> also help to point to where the behavior is actually defined.
> In 4.2, step 7, it's not clear what "this" is in "publishes this"
> Suggest deleting "In some cases," from the start of 4.2 step 9.
> The second paragraph of 5.2.2 should be clearer - it's not obvious
> that what you're trying to recommend is that a UA not share dialog
> information so that it won't be possible for someone else to take the
> call from a remote peer.
> Section 5.3 : why are the SHOULDs in paragraphs 2 and 3 (not counting
> the note between them), SHOULD and not MUST?
> Section 5.3, paragraph 3: Should this say "fails or loops back to itself"?
> Or is looping back the only failure you were intending to describe? What
> period should UAs retry the subscription with?
> Section 5.3, paragraph 4 "All User Agents supporting INVITE MUST support...".
> This hasn't captured the real requirement - it's not All User agents that
> support INVITE in the world - did you intend to scope this to "implement
> call pickup, joining, and bridging as you did in the first sentence?
> Section 5.3, top of page 15: "This publication state SHOULD be refreshed"
> Why is this a SHOULD? When would the endpoint choose to let the published
> state expire? It might help to call out that you are talking about normal
> 3903/5264 soft-state refreshes here.
> Section 5.3, middle of page 15: what does "implicitly rendered" mean?
> End of section 5.3 - informative note. typo: received->receive. It would
> probably help to call out that this NOTIFY will be on the dialog event
> package.
> Section 5.4 - The SHOULD at the end of the 2nd paragraph is either
> modifying or restating a requirement from 4235. The Appearance Agent
> is being a State Agent at this point and the event package defines
> when change is sufficient to trigger a NOTIFY. It looks like this is
> in fact modifying the rules in 4235, adding extra conditions on
> when NOTIFYs would be sent. It would be much clearer to state this in
> terms of the affect on the package.
> 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.
> Section 5.4, next to last paragraph on page 17, last sentence,
> starting "An Appearance agent does not have to". What does this mean
> in terms of protocol - is it suppressing a publish, a notify?
> Section 5.4, 2nd paragraph page 18 : Is this trying to say use
> event-rate-control? Or is it modifying the definition of the event package?
> 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?
> Section 7.1.1 - is this "0" an example, or is it intended that Single appearance UAs
> only use "0" and any other values are not allowed? Section 7.1.2 doesn't seem to have
> the same level of requirements that this section has.
> Section 7.1.3 - when you say call should be ignored, do you mean requests should be
> rejected?
> Should the list starting with "The problems faced by each style" be its own section
> or is it intended to be part of section 7.1.4?
> Section 8.2 - You should call out that if enpdoints use end-to-end encryption
> for their session descriptions, the Appearance agent will not get this information.
> This and other factors may make the information the appearance agent has imperfect.
> Seciton 8.3 - what's the consequence of not rejecting the requests - that exlusive
> calls get joined?
> Section 9 first paragraph - call out the event package (and that you are probing
> for support of the extension via the event header parameter).
> I'm not sure what the second paragraph of section 9 is trying to achieve?
> Section 10.1 : Do you want to also call out authorizing publishes? Suggest
> rephrasing to avoid using "the same".
> 10.1 -
> In general, the examples need to be double-checked for correctness.
> The request and response in F1, and F2 do not have the same branch-id.
> F2 should have its expiry on the Contact header field value
> F5's Subscription-State header does not have the required elements (expires,
> at least, is required). This occurs in other examples as well.
> There should be no Event header field in F6.
> 10.2 F4 and F21 have the same CSeq and the same partial-notification
> version number.
> 10.3 F4 and F6 are from different subscriptions - it's _very unlikely_
> that the partial notify bodies would have the same version. I need to
> check, but I think the id attribute to <dialog is also scoped to the subscription.
> 10.4 F1 : Are you sure about using a partial publish here?
> 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?
> 10.13: This is really hard to follow - it might help to tag the subscribes with
> what's being subscribed to.
> 10.14 : F48 - How is Alice authoritative for telling the appearance agent that
> the dialog in that Publish has been terminated?
> 11 - What text precludes a UA from putting in its own appearance number?
> 11 - it would be prudent to reconcile this ABNF change with what SALUD
> plans to do. We should make it where new parameters can be added with /=
> after this change.
> 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?
> _______________________________________________
> BLISS mailing list