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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
