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

[Alan Johnston <[e-mail]>]

Robert,

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bliss
>