My apologies for not getting to this sooner, but November was a busy
month for me.
Comments on draft-ietf-bliss-shared-appearances-04:
Technical items
T1. In 4.2 items 1 and 2, it is asserted that a successful dialog event
by a UA subscription to its AOR indicates the presence of an
Appearance Agent. But this is not so -- there may be a state agent
that does not support SA. The correct test seems to be:
1. A UA is configured with the AOR of a shared appearance group.
It registers against the AOR, then attempts a dialog state
subscription to the AOR with the "shared" parameter, that is,
with "Event: dialog;shared". If the subscription fails or loops
back to itself, the UA knows there is no State Agent, and hence
no Appearance Agent and this feature is not implemented.
2. If the subscription receives a 200 OK, the UA knows there is a
State Agent If the resulting NOTIFYs contain "Event:
dialog;shared" rather than "Event: dialog", then the State
Agent is an Appearance Agent that this feature is implemented.
The UA then follows the steps in this list.
T2. In 5, perhaps between 5.1 and 5.2 should be a normative description of
appearance numbers, along these lines:
Each AOR that implements Shared Appearances has a separate set of
appearance numbers, which are consecutive integers starting at
zero, running to some upper limit.
Most dialog endpoints at an implementing AOR will be assigned an
appearance number. This appearance number (or lack thereof) will
not change during the life of the dialog, and, except as provided
herein, will not be shared with any other dialog endpoint.
The two endpoints of a dialog are assigned appearance numbers
independently of each other, even if they are to/from the same
AOR.
A dialog which replaces or joins another dialog may share the
appearance number of the replaced/joined dialog.
The originating endpoints of multiple dialogs which are created by
a single INVITE perforce share the same appearance number.
Note that this description includes a number of technical issues,
viz., (1) that the two endpoints of a dialog are assigned appearance
numbers independently (see also comments on 10.8), (2) that the
appearance number of a dialog cannot be changed (see also comments on
10.2), and (3) the originating endpoints of multiple dialogs created
by a single INVITE share the same appearance number (for their
duration).
T3. In 5.1 item 3 is "A forking proxy server that can communicate with the
State Agent". Technically, the information that must be communicated
between the forking proxy and the Appearance Agent should be
specified. Note that it is not required that the forking proxy send
dialog state data to the Appearance Agent (as the AA can obtain it
from subscriptions). The minimum requirement is that the forking
proxy uses the Appearance Agent to allocate appearance numbers to
incoming dialog requests, and that can be done without any "special"
data path. (E.g., by sending the request to the Appearance Agent,
which would attach a suitable Alert-Info header field via a
redirection response. See section 11.)
T4. In 5.2.2, the default value of the <exclusive> element needs to be
specified, i.e., the effect if <exclusive> is omitted from a <dialog>.
T5. In 5.3 is a repetition of the "subscription test" of 4.2 item 1, and
it needs the same clarifications.
T6. In 5.3 in order to allow a subscribing UA to accurately know whether a
notifier is an Appearance Agent that supports SA, it seems that the
NOTIFY Event header fields MUST include the 'shared' parameter, rather
than just SHOULD include it. If we do not make this a MUST, the
dialog events need some other indicator of this fact. (The extension
elements do not suffice, as a dialog event with zero dialogs will
never contain an extension element.)
T7. In 5.3 there should be a description of the correspondence/interaction
between PUBLISHs sent by a UA to the AA and NOTIFYs sent by the UA to
the AA (when the AA is using such subscriptions). The central
questions seem to be:
The correspondence between the <dialog> 'id' values in the
PUBLISHs and NOTIFYs.
Whether or not a NOTIFY containing a dialog with an appearance
number constitutes a refreshment of the appearance number
assignment. This determines whether the UA can send NOTIFYs
every 60 seconds instead of sending PUBLISHs every 60 seconds.
T8. In 5.3, in regard to preventing pickup/join, it would be helpful if
some guidance was provided as to what specific information should be
concealed. As far as I can see, one needs to conceal the identity and
target URIs (to prevent the remote UA from being queried directly for
the dialog identifiers) and to replace consistently the call-id with a
generated unique pseudo-random value. The tags should remain
unchanged so as to assure that (e.g.) multiple dialogs generated by a
single INVITE remain distinct. And perhaps we should establish a
convention as to how the generated call-id appears so as to avoid
confusing someone trying to debug the system, e.g., suggest that the
generated call-id start with "exclusive:". The identity/target URIs
should be replaced with an "anonymous" URI rather than being deleted,
so that any parameters (especially "+sip.rendering") can be carried
normally.
T9. It isn't clear (to me) exactly what actions need to be taken by
the UA to seize and hold an appearance number. There is relevant text
in In 5.3, 5.4, and 10.4, but it is not consistent.
In 5.3 is "Once the dialog has transitioned to the confirmed state, no
publication refreshes are necessary.". But this contradicts the
statement in 10.4 "As long as Bob is using the appearance number, he
must refresh the publication every 60 seconds or loose the
appearance."
In 5.4 is another discussion of the expiration time of PUBLISHed
appearance numbers. This needs to be reconciled with the text in 5.3
and 10.4.
In 10.4 is "As long as Bob is using the appearance number, he must
refresh the publication every 60 seconds or loose the appearance."
This seems to contradict text in 5.2 and 5.3.
T10. In 5.4 is "If an INVITE is sent and no appearance number is
available, the proxy MAY reject the INVITE with a 403 Forbidden
response code." Is any alternative behavior possible? E.g., should
we add, "Alternatively, the Appearance Agent may choose to not assign
an appearance number to the dialog."
T11. In 6, should the minOccurs and maxOccurs attributes be present,
since the <element>s are children of <schema>? It doesn't look like
the XML Schema Language allows that.
T12. In 9, it is stated that a UA can discover whether SA is available for
a given AOR. But this seems to not be true in the common case where a
central system provides dialog events for all AORs, but the central
system does not support SA -- in that case, a SUBSCRIBE to the AOR
with ";shared" will be accepted (since the notifier ignores ";shared",
not knowing what it means), and the subscription will not loop to the
requesting UA. A new attribute could be added to the <dialog-info>
element, or better, the Event header field of the NOTIFYs could be
tested for the "shared" parameter.
T13. In 10.2 is "However, if Carol answers both Alice and Bob and keeps
both dialogs active, then the Appearance Agent will need to resolve
the situation by moving either Alice or Bob's dialog to a different
appearance." But there is no defined operation for changing the
appearance number of a dialog that is in progress, and there is no
guarantee that the participating UA can render the new appearance
number. (E.g., suppose Alice's UA is a single-line UA, and the AA
tries to move Alice's dialog to appearance number 1.) This seems to
require that multiple dialogs generated by one INVITE be allowed to
keep using the same appearance number, or alternatively, that we
define how the appearance number of an established dialog can be
changed.
T14. In 10.8, the overall logic seems to be incorrect, at least if the
intention is to simulate a key system and/or to handle this situation
as a logical extension of the previous cases: The originating and the
terminating ends of the call should be on separate appearances. But
the events shown assign the same appearance number to both ends of the
call.
Not treating the two ends of the call separately is actually
constructing a special case for how these calls are to be handled, but
there is no normative text describing how this special case is to be
handled, and no discussion of whether treating this as a special case
would cause problems. Much better, IMHO, would be to treat this
situation via the general case, where the UAC seizes an appearance
number for the originating end, sends the INVITE, the proxy assigns
another appearance number for the terminating end, and everything
works as normal.
Editorial items
E1. In 1 is "This document looks at how this feature can be implemented",
but the section does not clearly state that the document specifies a
method of implementation. (This seems to be a remnant from when the
text was used in a requirements-definition or
implementation-comparison document. See also comments about section
11.)
E2. In 1 is "In traditional telephony, the line is physical." Let us be
explicit about this and say, "In traditional telephony, the line is
physical, a single copper pair that runs to the central office."
E3. In 1, "typically each appearance or an AOR" should be "typically each
appearance { of } an AOR".
E4. In 1, "visual display" would probably be better as "visual indicator".
E5. In 3.2, "Users with similar business needs or tasks can be assigned to
specific groups and share the line appearances of each other on each
others SIP telephony devices." is awkward. Perhaps better phrased as
"... and share each other's line appearances on their SIP telephony
devices."
E6.In 3.3, "If another UA in the group seizes the line (i.e. goes off
hook)," would probably be better as "If another UA in the group
selects an appearance with an active call (i.e. goes off hook),".
E7. In 4.1 REQ-9, "incoming session request" should probably be "incoming
dialog request".
E8. In 4.2 item 1: "If the subscription fails, loops back to itself, or
returns an error, it knows there is no State Agent...". In 5.3, "If
the SUBSCRIBE request fails or loops back to itself, then no Appearance
Agent is present...". Both seem to be poorly phrased, and should be
"...fails or loops back to the UA itself...". ("fails" and "returns
an error" are equivalent.)
E9. In 4.2 item 8, "Since the same appearance number is used for these
types of operations, this information is published prior to sending
the INVITE Join or INVITE Replaces." would be better explained as
"Since the new dialog uses the same appearance number as the target
dialog, the new dialog's appearance number is published prior to
sending the INVITE Join or INVITE Replaces."
E10. In 4.2 item 9, "the Appearance Agent may not have full access" would
be more clearly stated as "the Appearance Agent may not have { direct
} access".
E11. In 5 item "Seizing", the end of the paragraph would be clearer as:
... communicating an artificial state of "trying" prior to actually
initiating a dialog, in order to appear as { if the UA } was
already initiating a dialog. { The UA waits until the allocation
of the appearance number is confirmed } prior to sending the
INVITE.
E12. In 5.1 item 3 is "A forking proxy server that can communicate with the
State Agent". For consistency, this item should end with a period,
and "State Agent" should be "Appearance Agent".
E13. In 5.2, reference to I-D.ietf-sipcore-rfc3265bis is incorrect, as
the dialog event package is defined in RFC 4235.
E14. In 5.2.1 should be added, "The absence of an <appearance> element for
a <dialog> element from a notifier that implements Shared Appearances
indicates that the dialog is not assigned an appearance number."
E15. In 5.2.2 is "The <exclusive> element is a boolean used to indicate
whether the UA will accept Join or Replaces INVITEs for this dialog.".
This could be clarified to:
The <exclusive> element is a boolean used to indicate whether this
dialog is allowed to be the target of a pickup or join action. As an XML
boolean value, its content is "true" or "false". The default value is
{ what??? }. If <exclusive> is "true", the UA will not accept a Join or
Replaces INVITE for this dialog, and other UAs should not issue them.
E16. In 5.3 is:
The presence of the 'shared' Event package parameter tells the
Appearance Agent that this UA supports this specification.
However, this should be generalized, as it (e.g.) also is how the UA
determines that a State Agent supports this specification:
The presence of the 'shared' Event package parameter tells the
recipient that the sender supports this specification.
E17. In 5.3 there should probably be a note that as an event state
compositor, the AA may generate new <dialog> 'id' values in the
NOTIFYs it generates (relative to the 'id' values in the
PUBLISHs/NOTIFYs it receives). (This is described in passing in 10.4,
but it should be noted in a normative section.)
E18. In 5.3 is "Dialog identification includes local and remote target URIs
..." which should be expanded to "Dialog identification includes local
and remote { identity and } target URIs". The reason to include
identity URIs is that very often the target UA can be effectively
reached through its identity URI, so hiding the target without hiding
the identity provides no additional security.
E19. In 5.3 item 1 is "It registers against the AOR ..." should be
clarified as "It registers (once) against the AOR ...", because some
SA proposals have included registration once for each appearance
number.
E20. In 5.3, items 2 to 4, the text is not very clear about what moment the
PUBLISH should be sent. Each should start with "Before sending the
INVITE when ...". In addition, there should be an item listing when
PUBLISHs need to be sent periodically by a UA to continue to hold an
appearance number. (The latter interacts with the question of whether
a NOTIFY holds an appearance number.)
E21. In 5.4 is "The Appearance Agent MUST support publications and
subscriptions for this event package.". This would be clearer as "The
Appearance Agent MUST be a UAS for publications and a notifier for
subscriptions for this event package."
E22. In 5.4 is "... also to pass the appearance number to the proxy to
insert in the Alert-Info header field." would be clearer as "... also
to pass the appearance number to the proxy to insert in the Alert-Info
header field { of incoming INVITEs to the AOR }."
E23. In 5.4 is "... if a PUBLISH has not been received selecting/seizing a
particular appearance number" would be clearer as "if a PUBLISH has
not been received selecting/seizing a particular appearance number {
or specifying that no appearance number is to be assigned }".
E24. In 6, indenting of XML in the schema is inconsistent.
E25. In 6, the XML schema describes the new elements but does not describe
where in the larger <dialog-info> it is valid to place them. I'm not
sure that XML Schema Language provides a way to do this, though. In
any case, the text in 5.2, "The elements are <appearance>,
<exclusive>, <joined-dialog>, and <replaced-dialog> which are
sub-elements of the <dialog> element." should be replicated here, so
that 6 is a reasonably complete syntax of the new elements within the
dialog event package.
E26. In 7, the last sentence uses "also" twice.
E27. In 7.1 et seq., the descriptions of the UA types don't really describe
how the appearances are managed.
Suggested improvements to these sections are { inside braces }:
7.1.1. Single Appearance UAs
These devices are constrained by only having the capability of
displaying status indications for a single call. { Thus, the device
must annotate all calls it makes with a fixed appearance number
(usually "0"), and must display only the status of calls with
that appearance number. Any incoming call indications
for appearances other than for that appearance number should be
rejected with a 486 or 480 response. }
7.1.2. Dual Appearance UAs
These devices are essentially single appearance phones that implement
call waiting. They have a very simple user interface that allows
them to switch between two appearances (toggle or flash hook) and
perhaps audible tones to indicate the status of the other appearance.
{ Thus, the device
must annotate all calls it makes with one of two fixed appearance numbers
(usually "0" and "1"), and must display only the status
of calls with
those appearance numbers. Any incoming call indications
for appearances other than for those appearance numbers should
be rejected with a 486 or 480 response. }
7.1.3. Shared Appearance UAs with Fixed Appearance Number
This UA is the typical 'business-class' hard-phone. A number of
appearances are typically configured statically and labeled on
buttons, and calls may be managed using these configured appearances.
Any calls outside this range should be ignored, and not mapped to a
free button. Users of these devices often seize specific appearance
numbers for outgoing calls, and the UA will need to seize the
appearance number and wait for confirmation from the Appearance Agent
before proceeding with { a call } .
7.1.4. Shared Appearance UAs with Variable Appearance Number
This UA is typically a soft-phone or graphically rich user interface
hard-phone. In these cases, even the idea of an appearance { number }
may
seem unnecessary. However, for these phones to be able to interwork
successfully with other phone types, it is important that they still
use the appearance { number } to govern the order of appearance of calls
in progress. No specific guidance on presentation is given except
that the { presentation order should reflect the ordering of
appearance numbers } . Thought should also be given to
how an appearance number that has no call associated with it should
be rendered to the user. These devices can typically make calls
without waiting for confirmation from the Appearance Agent {
regarding } the
appearance number.
[...]
4. A third call arrives, and is assigned the appearance number of 0.
All UAs should be able to render the arrival of this new call to
the user. Multiple appearance UAs should continue to indicate the
presence of the second call, and should also ensure that the
{ order of presentation of calls is that of the appearance
numbers and not the order of call arrival } .
E28. In 7.1.4, uses "appearance index", but "index" is used nowhere else in
the draft. That probably should be "appearance number".
E29. In 7.1.4, the text from "The problems faced by each style" to the end
does not seem to be part of 7.1.4, but rather of section 7.1. Perhaps
it should be moved to 7.1, between the two existing paragraphs.
E30. In 8.2, "such as hold, etc" does not put a period after "etc".
E31. Sections 8.1, 8.2, and 8.3 appear to be co-equal, but the first two
regard one topic and 8.3 regards another topic. Instead, the last
paragraph of 8 should become the first paragraph of a new 8.1, of
which the current 8.1 and 8.2 should become subordinates. (8.3 is
then renumbered as 8.2.) Since the current 8.1 and 8.2 are short,
perhaps they should be combined to form the new 8.1 without
sectioning, rather than making them the new 8.1.1 and 8.1.2.
E32. In 10, "the Appearance Agent is aware of dialog state events" would be
better phrased "the Appearance Agent is directly aware of dialog
state".
E33. In 10.3, "the appearance assigns" should be "the appearance agent
assigns".
E34. In 10.4 is "Before sending the outgoing INVITE request, Bob publishes
to the state agent that Alice line appearance is in (trying) state.",
which doesn't parse. Presumably "Alice" is incorrect or incomplete.
E35. In 10.4 is "Note the shortened expiration interval in F2 of 60
seconds." The significance of this needs to be explained more
carefully.
E36. In 10.4 is:
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
direction="initiator">
It appears that the final line is not indented correctly.
E37. In 10.6 is "Bob publishes the termination of the dialog", but the
flow diagram and the listing of messages does not show such
publishing.
E38. In 10.7 is "has a established session" which should be "has an
established session".
E39. In 10.7 is "an attempt to pickup" which should be "an attempt to pick
up". ("pick up" is the verb, "pickup" is the noun.)
E40. In 10.7 is:
<dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" >
which seems to have the indentation and spacing (before ">") damaged.
E41. Section 10.8 could use some more descriptive text explaining the
sequence of operations.
E42. In 10.8, the text is not clear that the call is between AORs that are
both in the appearance group. (UAs per se are not in an appearance
group, they have AORs that are (and perhaps some that are not.) What
is happening is that the UAC is "calling out on" an AOR that is also
the destination AOR.
E43. In 10.9 is "Bob will publish the termination of the dialog with Carol
and also publish the appearance with the dialog with Alice", but it
would be better described as "Bob will publish the termination of the
dialog with Carol and (simultaneously) the appearance with the dialog
with Alice". The two operations need to be in one PUBLISH request to
prevent any opportunity for another UA to seize the appearance. The
latter case should be illustrated.
E44. In 10.11 is a reference to messages R24 and F26, but there are no such
messages in the flow diagram. Presumably they should be F14 and F16.
E45. In 10.13, there should be a sentence or two describing the calling
operations that are illustrated in the flow diagram.
E46. In 10.14 is "Alice cancels the pickup attempt with the PUBLISH F48."
This would be better stated as "Alice reports the failure of the
attempted pickup attempt with PUBLISH F48.", since Alice didn't cancel
the pickup attempt, she tried and it failed.
E47. Why is section 11, "Incoming Appearance Assignment" not part of
section 5, "Normative Description"?
E48. In 11 is "follows normal policies Alert-Info policies", which must be
a mistake.
E49. In 11 is "a normal ringtone should be indicated using the
urn:alert:tone:normal in the Alert-Info", which would be better
phrased "a normal ringtone should be indicated using the URI
urn:alert:tone:normal in the Alert-Info header field".
E50. In 11 is:
appearance-param = "appearance" EQUAL *DIGIT
Presumably this is supposed to be:
appearance-param = "appearance" EQUAL 1*DIGIT
E51. In 11, the text does describes several approaches as possible, but
does not make it clear what approach (or combination of approaches) is
required of the system.
E52. In 12, IANA Considerations, the 409 response code is not listed, but I
do not see it listed in the IANA registry. Is the 409 response new?
If so, it needs to be specified in IANA Considerations.
E53. In 14, "Event Package for Dialog State as define in" should be "Event
Package for Dialog State as defined in [RFC4235]".
E54. Section 14 refers to a number of RFCs, but none of them are listed as
Normative References. It seems to me that any RFC that is "included
by reference" into the Security Considerations should be listed as a
Normative Reference.
Dale
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
