I basically agree with Paul. Because there was a market need for the functionality, various non standard mechanisms have been developed to address the need until a standardized mechanism becomes available.
If the working group does not think there is need for a standardized solution, so be it. However vendors which don't like the non standard mechanisms or haven't yet implemented the common ones would likely desire the work to continue. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Paul Kyzivat > Sent: Friday, March 21, 2008 12:16 AM > To: Francois Audet > Cc: Rohan Mahy; [email protected] > Subject: Re: [BLISS] MLA with Floor Control > > I'm not promoting one way or the other. Ultimately people > building products will build the functionality they think > they need to sell their products. If people feel this is > important then they will want a way to do it. If it isn't > standard then it will be nonstandard. > > Paul > > Francois Audet wrote: > > > > > >> There is a tradeoff... > >> > >> If multiple extensions can place outgoing calls from the > same line, > >> then the line doesn't have "binary" status, so it can't be > indicated > >> as active or not with a light. And you can't "conference in" by > >> picking up on the same line. > >> > >> While I am not into it myself, I can see how someone can build a > >> "business process" around the specific way in which lines > are managed > >> by the phones, and then be very upset if they can't get that same > >> user experience. > > > > Yeah, sure, it's doable. I do not believe that adding the > concept of a > > Line number to do this is required to do this, or even desireable. > > > >> Now you can come up with some very nice UIs that provide > better user > >> experience, if you have a suitable display instead of just > a bunch of > >> lights. (E.g. an entry for the "number" (AOR that people > call), and a > >> variable length drop down list of active calls, showing > the callerid > >> of the caller, how long it has been active, and which > extensions are > >> currently connected to it.) But that is *different*, and > requires a > >> device with richer UI. > > > > Agreed. > > > > My point is that we shouldn't bastardize the protocol with all this > > complex extra protocol (Line numbers, BFCP, NOTIFY/PUBLISH-storms, > > etc.) just do do this. > > > > The basic "single-lamp" based approach is doable without > any of this. > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
