Francois,
Thanks for the review - I somehow lost track of it. I think I have
addressed nearly all of your comments in the latest revision. See my
comments below.
Thanks,
Alan
Francois Audet wrote:
This is my expert review on draft-ietf-bliss-shared-appearances-02.
Overall, document is in good shape and has no major issue. It would benefit
from removing a lot of the "historical" or "discussion" material that is
not relevant anymore.
Also, I make some recommendation on how to make the Call flow examples clearer.
This review also highlights the need for up-issuing
draft-alexeitsev-bliss-alert-infor-urns
(which is also needed by external standards bodies).
---------------------
Section 1:
4th paragraph.
NIT: incomplete sentence "...what gives this feature its.".
NIT: s/lamp that can change color or blink/e.g.. a lamp that can change color
or blink, or
an screen icon
Done.
Section 4.2:
p. 9, 2nd full paragraph: s/not discussed in this draft but instead is left as a
research project for future standardization/outside the scope of this draft
Done.
p. 10, bullet 5: Reword as follows:
5. For outgoing calls, the operation depends on the implementation.
If line seizing is supported, the UA publishes this information and
waits for a 200 OK before sending the INVITE.
(In other words, some implentations may allow for the user to "select" the
appearance
by pressing the button, but not seize the line. For that same reason, I'm changing
"select"
to "seize" in a few places in the document).
I changed "select" to "select/seize" globally in the document. I'm not
sure it helps readability, but I think we need both terms.
Section 5.3:
p. 13, bullet 1: Reword as follows (this is same as previous point):
1. When the user selects a particular appearance number for an outgoing
and wishes to seize the apperance and appearing "off-hook" (if the UA's
user interface uses this methaphor).
Done.
2nd paragraph after numbered items: s/UA selects/UA seizes
This section needs to describe that either a PUBLISH model or a SUBSCRIBE model can
be used for the state/appearance information to be sent to the Appearance Agent.
Currently, it appears written for the PUBLISH model only. The SUBSCRIBE model, as
illustrated in section 10.13, is very useful for cases where the Appearance Agent
is a stand-alone UA that does not share state/appearance information with the
Proxy/B2BUA. This section also needs to describe that when the SUBSCRIBE model
is used,
the NOTIFY message is sent to "seize" a line (there is no need for a PUBLISH in
this case).
(I'm assuming I'm right: let's discuss if not).
Good catch. The draft is silent on this right now, so I've marked it as
an open issue. One one hand, I'd prefer to have only one mechanism
(PUBLISH) for selection/seizure. On the other hand, if the Appearance
Agent has subscribed, and the UA is sending NOTIFYs, it hardly makes
sense to mix PUBLISH into it.
Section 8:
Remove Editor's note.
Done.
Section 9:
Delete first paragraph.
Clarify the UA also REGISTERs to the AOR. Discuss the security implications,
i.e.,
you either use the same shared username/password, or you use a different
username/password
for HTTP digest, per user. Perhaps the security considerations can be described
in section 15.
I added text about authorization for third party registrations and
publication. A little more text on this would be helpful.
Section 10:
General:
The call flows are confusing because Alice is both the end user AOR, as well as
the
shared apperance AOR. This makes it very difficult to follow the call flows.
I would like all the call flows to use Alice and Bob as the Endpoint, and the
shared
AOR to be, say, [email protected] (or something similar). See below for
details.
I agree 100%. I have changed the shared AOR to be
sip:[email protected] and I think this makes things clearer. We need
to make sure I've made all the correct substitutions in the call flows.
Section 10.1:
p. 22, 2nd paragraph: delete "or Appearance Agent" at end of paragraph.
Actually, this is correct, as I am talking about registrations refresh
with the Registrar and subscription refresh with the Appearance Agent.
Here's the sentence:
"Also note that registrations and subscriptions must all be refreshed
by Alice at intervals determined by the expiration intervals returned
by the Registrar or Appearance Agent."
Maybe it should say Registrar and Appearance Agent?
Figure 1 and Call Flow: I would like to also see Bob's registration, to
illustrate the idea that Alice and Bob share the same AOR for both
registration and subscription.
Done.
Something like this:
Registrar Appearance Agent Alice Bob
| | | |
| | | |
|<--------------------------- REGISTER F1<| |
| | | |
|>F2 200 OK ----------------------------->| |
| | | |
| |<----- SUBSCRIBE F3<| |
| | | |
| |>F4 202 Accepted -->| |
| | | |
| |>F5 NOTIFY -------->| |
| | | |
| |<-------- 200 OK F6<| |
| | | |
|<--------------------------- REGISTER F7---------------<|
| | | |
|>F8 200 OK -------------------------------------------->|
| | | |
| |<----- SUBSCRIBE F9---------------<|
| | | |
| |>---------F10 202 Accepted ------->|
| | | |
| |>--------F11 NOTIFY -------------->|
| | | |
| |<-------- 200 OK F12--------------<|
The, in the call flows, all the To headers for REGISTER
and SUBSCRIBE are <sip:[email protected]> instead of
<sip:[email protected]>.
I REALLY think this will make the spec much more readable.
Question: Why is "202" used for responding to SUBSCRIBE instead of "200"? If
202 is used, I think it deserves an explanation in the document.
Isn't 202 commonly immediately returned, and then the NOTIFY confirms
the subscription state (i.e. active instead of pending)? I can change
it to 200 if this is more common behavior.
Section 10.2
Again, all the AOR in "To" headers should be <sip:[email protected]>
(e.g., F7 & F8). This will help reader's understanding.
Alert-Info in F7 should not use a <file://ring.pcm> example.
Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns.
For example:
Alert-Info: <urn:alert:tone>;alert=normal;appearances=1
This is done as well, thanks to Laura for being the editor of this draft!
Section 10.3
In first paragraph, s/selecting/seizing.
It would be useful to show the content of the NOTIFY messages going to Alice
(e.g., F4).
Done.
I'm a bit confused by this example. It shows Bob making a call NOT using an
appearance (i.e., From: Bob instead of From: sharedline). And then both Alice
and Bob are notified of Bob's state instead of the sharedline? Why is that
a shared appearance scenario???
Good catch! This was a mistake - it now uses the shared AOR.
Section 10.4
Title: s/Pre-Selection/Seizing
Again, use sip:[email protected] when appropriate.
It would be nice to see the content of message 7.
Done.
Section 10.5
Again, use sip:[email protected] when appropriate.
It would be nice to see the content of message 7.
It is the same as the previous message F7 - I put in a note saying that.
Section 10.7
Are messages F32-F35 necessary when line seizing is NOT used?
I think the answer is "no, they would not be used if there is no
line seizing". If so, I'd like to see a note explaining it.
They are necessary for the Replaces and Join cases. I added this text:
"Alice must
PUBLISH F32 to indicate that the INVITE F38 will be an attempt to
pickup the dialog between Carol and Bob, and hence may use the same
appearance number."
Section 10.9
Are messages F32-F33 necessary when line seizing is NOT used?
I think the answer is "no, they would not be used if there is no
line seizing". If so, I'd like to see a note explaining it.
Again, they are necessary (this flow is now 10.10).
Section 10.10
Are messages F22-F23 necessary when line seizing is NOT used?
I think the answer is "no, they would not be used if there is no
line seizing". If so, I'd like to see a note explaining it.
Section 10.13
If the Appearance Agent subscribes to Bob's dialog-event package (as
in this example), is the expectation that Bob would never really use
PUBLISH, and rather, would always use NOTIFY? I am assuming that the
answer is yes.
We do need to resolve this and document the right answer.
I am also assuming that it would even be the case for the line
seizing mechanism. Is this correct?
If this is the case, it would be useful to section 10 (before the
individual call flows) that all the sections expect 1.13 use a model
where the Appearance agent does NOT use a subscription model, but a
publish model instead. And then add a note that if a subscription model
was used instead, there would be NOTIFYs instead of PUBLISHes, as per
section 10.13.
OK, I meant to include this text but left it out. I think it is a good
idea.
Section 11.1
First line: delete "also".
Done.
Section 12 Appendix A
This whole section should not be an Appendix and should be moved to the core
document; it seems this section is necessary for REQ-9.
Alert-Info should not use a <file://ring.pcm> example.
Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns.
For example:
Alert-Info: <urn:alert:tone>;alert=normal;appearances=1
(I think that "tone" one is the default, so we can get rid of the OPEN issue.
Need to add draft-alexeitsev-bliss-alert-infor-urns to References. Also need
to up-issue that draft and move it forward).
Right, done.
Section 13: Appendix B
I think it is time to remove this whole Appendix B. This whole section was
useful
reference when we were discussing various options, but now, it is totally out of
place since the choices have been made.
Done.
Section 15: Security Considerations
See comment on section 9.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
