[BLISS] Comments on draft-ietf-bliss-shared-appearances-07

["Worley, Dale R (Dale)" <[e-mail]>]

I've finally gotten the cycles to go over draft-ietf-bliss-shared-appearances-07.  We consider this work to be seriously important for the use of SIP in the business telecom market, and want to see Shared Appearances standardized.  Unfortunately, I'm too pressed for time to have examined these items a second time, so please forgive the mistakes in my queries.

Dale
----------------------------------------------------------------------
section 1:

This paragraph is awkward:

   This document looks at how this feature can be implemented using
   standard SIP [RFC3261] in conjunction with SIP events
   [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for
   exchanging status among user agents, and the SIP dialog state event
   package [RFC4235] to exchange dialog state information to achieve the
   same.

Perhaps:

   This document looks at how this feature can be implemented using
   standard SIP [RFC3261] in conjunction with SIP events
   [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903]
   (carrying the SIP dialog state event package [RFC4235])
   for exchanging status among user agents.

section 1:

   The appearance number relates to the
   user interface for the telephone - typically each appearance of an
   AOR has a visual display (lamp that can change color or blink or a
   screen icon) and a button (used to select the appearance).

Might be better as:

   The appearance number relates to the
   user interface for the telephone - typically each appearance of an
   AOR has a visual display (lamp that can change color or blink or a
   screen icon) and a button (used to select the appearance) - where
   each appearance number is associated with a different dialog to/from
   the AOR.

section 1:

   If a telephone has enough buttons/lamps, calls could be
   presented on the nth button.

Would be clearer as:

   If a telephone has enough buttons/lamps, the appearance number could be
   the positional sequence number of the button.

section 4.1, REQ-14:

   Exclusivity means that the UA
   requesting it desires to have a private conversation with the
   external party and other UAs must not be allowed to be joined or
   taken.

is not correctly phrased.  Correct to:

   Exclusivity means that the UA
   requesting it desires to have a private conversation with the
   external party and other UAs must not be allowed to joined or
   take the call.

section 4.2:

   While an Appearance Agent can be
   part of a centralized server, it could also be co-resident in a
   member User Agent who has taken on this functionality for a group.

"who" should be "which".

section 4.2, step 5:

       For outgoing calls, the operation depends on the implementation.
       If the user seizes a particular appearance number for the call,
       the UA publishes the 100 Trying state dialog information without
       an appearance number and waits for a 200 OK before sending the
       INVITE.

This appears to be incorrect.  I think the correct version is:

       For outgoing calls, the operation depends on the implementation.
       If the user seizes a particular appearance number for the call,
       the UA publishes the >>"trying"<< state dialog information >>with
       the<< appearance number and waits for a >>2xx<< before sending the
       INVITE.

section 4.2, step 7:

       For outgoing calls, if the user does not wish to seize an
       appearance (such as during a consultation call or if a UA is
       fetching 'service media' such as music on hold
       [I-D.worley-service-example]), the UA also publishes this prior
       to sending the INVITE.

"this" should be clarified (what exactly is published to indicate lack
of interest in receiving an appearance number?)

And I think that the question is not "does not wish to seize an
appearance" but rather "does not want an appearance number assigned",
as a UA can make a call without "seizing" (as defined in section 5),
but will have a number assigned automatically.

section 4.2, step 9:

       The Appearance Agent may not have full access to the complete
       dialog state of some or all of the UAs in the group.  If this is
       the case, the Appearance Agent will subscribe to the dialog state
       of individual UAs in the group to obtain this information.
       Normal notifications will be sent every time the dialog state
       changes, including calls placed, answered, placed on and off
       hold, and hangups.

This is hard to read until you realize that "may not have full access"
means "may not have back-door access".  A better phrasing would be:

       The Appearance Agent may not have direct access to the
       complete dialog state of some or all of the UAs in the group.
       If this is the case, the Appearance Agent will subscribe to the
       dialog state of individual UAs in the group to obtain this
       information.  In any case, the Appearance Agent will send
       normal notifications (via the subscriptions established by the
       UAs in step 1) every time the aggregate dialog state of the AOR
       changes, including when calls are placed, answered, placed on
       and off hold, and hung up.

section 5:

Somewhere near the beginning of section 5, it seems like a description
of the intended properties of appearance numbers is needed.  In
particular:

    Appearance numbers are non-negative integers.

    When an appearance number is requested to be assigned, generally
    the assigned number is the smallest nonnegative integer that is
    not currently assigned as an appearance number to a dialog for
    this AOR.

This rules out, e.g., having the appearance numbers be a dialog
sequence number that increments throughout the history of the AOR.

BTW, is the latest decision that appearance numbers start with 0,
rather than 1?

A word seems to be missing:

   [...] initiating a dialog, in order to appear as >>if<< it was
   already initiating a dialog.

The following sentence uses "confirmed", and several later sentences
use "confirmed by the Appearance Agent".  But there is no definition
of this "confirming" operation:

   The appearance number is confirmed prior to sending the INVITE.

The import of this sentence is unclear:

   This is a user interface only issue.

The sentence is also awkwardly phrased, as one would probably want to
construct "user-interface-only issue".  Less awkward would be:

    This is an issue only for the user interface.

or

    This is only a user interface issue.

But given that there are protocol actions involved, it's not clear why
that sentence is stated, or even exactly what "this" refers to.

section 5.2.1:

There is a lot that is not clear in this paragraph, and also a lot of
stealthy description of protocol actions hidden in a paragraph that is
ostensibly about a data item.  In addition, it does not state that
every <appearance> element is the child of a <dialog> element (nor
does the schema).

   The <appearance> element is used to convey the appearance number.
   The appearance number is a positive integer.  When sent in a
   publication in state Trying to the Appearance Agent, it is used to
   request an appearance number.  When sent by the Appearance Agent, it
   indicates that the appearance number is associated with a dialog.
   The UA generating the to-tag and from-tag parameters treats them from
   a local perspective.  In other words, if the UA sent out a request
   within the dialog, the to-tag parameter would match the remote tag,
   and the from-tag parameter would match the local tag.

Better would be:

   The <appearance> element is used to convey the appearance number of
   the dialog described by the <dialog> element which is its parent,
   on the UA(s) [for the AOR?] specified by the "entity" attribute.
   The appearance
   number is a positive integer.  When sent in a PUBLISH with parent
   <dialog> with state attribute "trying" by a UA to the Appearance
   Agent, the UA is requesting assignment of the given appearance
   number to the current or future dialog with the given dialog
   identifiers.  When an <appearance> element is sent by the
   Appearance Agent in a NOTIFY, it indicates that the appearance
   number has been assigned to the specified dialog.

   Note that a <dialog-info> element describes the contained <dialog>s
   "from the point of view of the UA" (named by the "entity" attribute),
   regardless of whether the containing request is sent by the UA or
   the Appearance Agent.  In particular, if the UA sent a request
   within the described dialog, the "To" header URI would match the
   <remote> <identity> value and the to-tag parameter would match the
   remote-tag attribute.  Similarly, the "From" header URI would match
   the <local> <identity> value and the from-tag parameter would match
   the local-tag attribute.

But this leads to the point that there is no clear, separate
description of the fundamental protocol action, viz., the UA sends a
PUBLISH to the Appearance Agent to request an appearance assignment
and the Appearance Agent sends a NOTIFY back to the UA with the final
assignment.

Also, this says that the appearance number is a "positive integer"
whereas appearance numbers are non-negative integers.

section 5.2.2:

   The <exclusive> element is a boolean used to indicate whether the UA
   will accept Join or Replaces INVITEs for this dialog.  For example,
   some shared appearance systems only allow call pickup when the call
   is on hold.  In this case, the <exclusive> element should be used to
   explicitly indicate this, rather than implicitly by the hold state.

could be clarified as:

   The <exclusive> element is a boolean, which when true, indicates
   that the UA is willing to accept an INVITE with a Join or Replaces
   header targeted to the dialog described by the <dialog> element
   that is the parent of the <exclusive> element.  For example, some
   shared appearance systems only allow call pickup when the call is
   on hold.  In this case, the <exclusive> element should be set to
   "true" when the call is held and "false" when the call is not held,
   rather than having the "exclusive" value implied by the hold state.

BTW, is there a default value for "exclusive"?  The schema doesn't
show one.

Expanding this sentence would help:

   It is important to note that this element is a hint, and that the
   UA must take additional steps to ensure that INVITE with Join or
   Replaces is not applied to the dialog.

section 5.2.3:

   Only the UA which is performing the actual media mixing
   should include this element in publications to the Appearance Agent.

This is not exactly correct, as the UA may be doing 3pcc to a mixing
agent.  What we want is:

   Only the UA which is the common endpoint of the mixed dialogs (and
   thus controlling the mixing operation) should include this element
   in publications to the Appearance Agent.

section 5.3:

Should probably add:

   User Agents which implement call pickup, joining and bridging MUST
   support sending >>and receiving<<< an INVITE with Replaces
   [RFC3891] or Join [RFC3911].

and omit the last sentence of the paragraph.  Or else, the
requirements are more complex than I understand them to be.

These two sections probably ought to be combined to clarify the
operations that are intended:

   A UA MUST send dialog package PUBLISH requests in the following
   situations:

   [...]

   In all these cases, the INVITE SHOULD NOT be sent until the 200 OK
   response to the PUBLISH has been received, except for an emergency
   call, when a UA MUST never wait for a confirmed seizure before
   sending an INVITE.  Instead, the emergency call MUST proceed
   regardless of the status of PUBLISH transaction.

viz.:

   In the following cases, before sending the INVITE, a UA MUST send a
   dialog package PUBLISH request to the Appearance Agent containing
   the forthcoming dialog state changes and receive the 2xx response:

   [...]

   An exception is an emergency call, when a UA MUST never wait for a
   confirmed seizure before sending an INVITE.  Instead, the emergency
   call MUST proceed without waiting for the PUBLISH transaction.

section 5.3, item 1:

I think "i.e." here should be "e.g.".

section 5.3:

It's not clear why this sentence using receipt of the 100 as a
criterion, as the receipt of the 100 does not provide any additional
dialog information:

   If no dialog identification information is present in
   the initial PUBLISH, the UA MUST PUBLISH again after receiving the
   100 Trying response.

I believe that what is wanted is "[...] the UA MUST publish again
promptly after the Call-Id and from-tag are established."

   This publication state is refreshed as described in [RFC3903] during
   the early dialog state or the Appearance Agent may reassign the

I think you want "This publication [published?] state MUST be
refreshed as described in [RFC3903] or the Appearance Agent may
reassign [...]"

It's not clear why PUBLISH refreshes are not required after transition
to the confirmed state, as RFC 3903 states that published data are
soft-state with specified expiration time.  If this I-D intends to
handle expiration differently from RFC 3903, this needs to be
specified clearly.

Shouldn't the following SHOULD be a MUST?

   A user may select an appearance number but then abandon placing a
   call (go back on hook).  In this case, the UA SHOULD free up the
   appearance number by removing the event state with a PUBLISH as
   described in [RFC3903].

section 5.3.1:

The first sentence would be clearer as:

   There are cases where two separate dialogs at a UA are not mixed
   but share the same 'context'.

The last sentence of the paragraph would be clearer as:

   These cases are best handled by not assigning an appearance number
   to a newly-created dialog when it shares a context with a
   pre-existing dialog.  (But if the pre-existing dialog is
   terminated, its appearance number should be reassigned to the
   newly-created dialog.)

This sentence could be clarified:

   If
   the Appearance Agent policy does not allow calls without an assigned
   appearance number, a 400 response with the reason phrase "Appearance
   Number Conflict" will be received, and the UA will republish either
   selecting/seizing an appearance number or send the INVITE without
   publishing, in which case the Appearance Agent will assign one.

as:

   If the Appearance Agent policy does not allow calls without an
   assigned appearance number, a the UA will receive a 400 response
   with the reason phrase "Appearance Number Conflict", and the UA
   must either republish selecting/seizing an appearance number or
   send the INVITE without publishing, in which case the Appearance
   Agent will assign an appearance number.

See also comments below about using 400 as a response code.

section 5.3.2:

This explanation probably needs to be fleshed out.  I can't visualize
what is expected to be published:

   When an INVITE is generated to attempt to bridge or take a call (i.e.
   contains Join or Replaces with a dialog identifier of another dialog
   in the shared appearance group), the appearance number of the joined
   or replaced call SHOULD be published.  The publication MUST contain
   the appearance number of the dialog to be joined or replaced and the
   dialog identifier in the 'joined-dialog' or 'replaced-dialog'
   elements.

section 5.3.3:

This paragraph contains a vicious passive construction, which
describes what is to be done but does not describe what is to do it:

   If Alice is the transferee, the triggered INVITE from the REFER
   should be treated as a consultation call, and should not use a new
   appearance number.  When the transfer completes, the appearance
   number associated with the dialog with Carol is moved to the dialog
   associated with David.

The last sentence should be "When the transfer completes, Alice's UA
publishes new state associating the appearance number of the former
dialog with Carol with the new dialog with David."

This paragraph isn't clear whether the incoming INVITE-with-Replaces
has no appearance number associated, or whether the AA should tag it
with the same appearance number.  It seems from the rest of the I-D,
that the new dialog should have no appearance number until the dialog
that is replaced is terminated, and then Alice's UA should assign the
old appearance number to the new dialog.  But that is not stated
clearly.

   If Alice is the target, the incoming INVITE should not have a new
   appearance number assigned.  Instead, it should reuse the appearance
   number associated with the dialog being replaced.  If the Appearance
   Agent does assign a different appearance number, when the transfer
   completes, Alice should release that appearance number and use the
   original appearance number associated with the dialog with Carol.

section 5.4:

The specification requires the use of a particular reason phrase,
"Appearance Number Conflict".  Making the reason phrase significant is
contrary to all previous SIP usage.  Wouldn't it be better to allocate
a specific 4xx response code?

section 6:

The schema gives the extension namespace as
"urn:ietf:params:xml:ns:sa-dialog-info-info" instead of
"urn:ietf:params:xml:ns:sa-dialog-info."

The indenting of the XML schema is irregular.

section 7:

        appearance-param = "appearance" EQUAL *DIGIT

is probably intended to require at least one digit, which would be:

        appearance-param = "appearance" EQUAL 1*DIGIT

section 8:

The design of the UI is strongly affected by the expected appearance
numbers.  My belief is that the intended design is that the appearance
nubmers will be small non-negative integers.  (See the item regarding
describing appearance numbers per se at the beginning of section 5.)
But there needs to be some stated policy regarding appearance numbers
that cannot be rendered by the UA.  Is the UA allowed to reject them?
Section 8.1.1 appears to allow rejection, but this fact is a
significant protocol action that should not be buried in an apparently
non-normative section about user-interface design.

section 8.2:

"sip+rendering=no" should be "+sip.rendering=no" in two places.

section 9:

Two uses of "interop", which should be "interoperation".

section 12 (Security Considerations) should reference or include this text
from 5.3, as it is a life-safety consideration:

   [For an emergency call, a] UA MUST never wait for a confirmed
   seizure before sending an INVITE.  Instead, the emergency call MUST
   proceed regardless of the status of PUBLISH transaction.

section 10:

I see three different descriptions of how to determine if SA is
available for a particuar AOR:

    section 4.2, REQ-1

           [A UA] attempts a dialog state subscription to the AOR.  If the
           subscription fails, loops back to itself, or returns an error,
           it knows there is no State Agent, and hence no Appearance Agent
           and this feature is not implemented.

    section 5.3

       Upon initialization, the UA MUST subscribe to the dialog event
       package of the AOR and refresh the subscription per the SIP Events
       Framework.  If the SUBSCRIBE request fails, then no Appearance Agent
       may be present and this feature is not active for this AOR.

    section 10

       UAs can automatically discover if this feature is active for an AOR
       by looking for the 'shared' Event header parameter in a response to a
       dialog package SUBSCRIBE to the AOR, so no provisioning for this is
       needed.

It would also be useful in practice if some hints were given for
interoperation with UAs that implement previous versions of this
work.  This probably can be limited to methods to detect which version
a particular UA implements.

section 11.8:

The description says that a call from one UA in a group to another UA
in the group would only use one appearance number.  This is not
uniform with the rest of the SA architecture and is not the behavior
of traditional key phone systems.  Are you sure you want to present it
this way?

section 11.13:

Another passive:

   Whenever Bob's dialog state changes, a NOTIFY is sent to the
   Appearance Agent who then notifies the other other UAs in the
   group.

should be:

   Whenever Bob's dialog state changes, Bob sends a NOTIFY to the
   Appearance Agent who then notifies the other other UAs in the
   group.

You probably want to change "who" to "which".
----------------------------------------------------------------------