[BLISS] Technical issues regarding draft-ietf-bliss-shared-appearances-07

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

To extract the technical questions from the editorial ones in my
comments:

It seems to me that the open technical questions are:

* Is the latest decision that appearance numbers start with 0, rather
  than 1?

Starting the numbering from 0 would be cleaner, but the customers will
universally count from 1, so all UAs are going to have to present
appearance numbers 1, 2, 3, ....  If the appearance numbers in the
protocol start with 0, all UAs will have to translate, which will
inevitably lead to errors.

* Is there a default value for "exclusive"?  The schema doesn't show
  one.

Inevitably people will omit the <exclusive> element, so we need to
decide what the implicit value is.  For simplicity, this default
should probably be the effective value for UAs that publish non-shared
dialog events, as the schema doesn't seem to be able to make
<exclusive> mandatory.

* 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.

I suggest that we not use PUBLISH in a way that is at all different
from RFC 3903 -- changes would make it impossible to use a general
PUBLISH toolkit as part of a SA UA.

* The specification requires the AA to reject proposed appearance
  number assignments by a 400 response with a particular reason
  phrase, "Appearance Number Conflict".

Making the reason phrase significant is contrary to all previous SIP
usage.  And using 400 (the generic failure message) to indicate a
specific meaning is hazardous.  Wouldn't it be better to allocate a
unique 4xx response code?  (There are over 50 available.)

* 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.

* The description in section 11.8 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 handle this call this way?

Dale