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

[Robert Sparks <[e-mail]>]

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.

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

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

----

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?