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
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
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).
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).
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).
Section 8:
Remove Editor's note.
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.
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.
Section 10.1:
p. 22, 2nd paragraph: delete "or Appearance Agent" at end of paragraph.
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.
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.
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
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).
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???
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.
Section 10.5
Again, use sip:[email protected] when appropriate.
It would be nice to see the content of message 7.
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.
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.
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.
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.
Section 11.1
First line: delete "also".
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).
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.
Section 15: Security Considerations
See comment on section 9.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
