I disagree. I think we need some clarification. We have decided already that the act of "fake publishing" a "trying" state is OPTIONAL in this draft. This feature is really when a vendor wants to mimic traditional behavior of a key system.
Other people view this as an archaic limitation instead. Even in "pre-sip" implementations, many TDM PBXs have given up already on "seizing" lines when you press the button (the "seizing" only occurs when the call is actually made). So, we wisely opted to make this optional in the spec. The problem is that we have a bit of lack of clarity in a few places about what that means. Getting to specifics, if you look at example 10.4 of the spec. If you use a "selection model" instead of a "seizing" model, then messages F1-F6 do not occur. And neigther would messages F10-F11. (Note that if the Appearance agent had subscribed to HelpDeksk's dialog state, then there would be NOTIFY instead of F10: that is the subject of another discussion). If we agree on this, I can volunteer to provide text if Alan wants it. But I'm not sure if "selection" is the proper term. An alternative would be to say the line is "Seized" or "Not Seized". > -----Original Message----- > From: Hutton, Andrew [mailto:[email protected]] > Sent: Wednesday, July 15, 2009 00:55 > To: Audet, Francois (SC100:3055); Alan Johnston > Cc: [email protected] > Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: > Seize vs Select > > Hi, > > If "select" is a local action in the UA to choose a "line" to > use and this determines the what is in the from header then > this is I believe out of scope for this draft which should > not mention selecting lines or AOR's as this is a different > feature. The SA draft is limited to sharing appearances of > the same AOR. > > Also if "select" is a local action at the UA that is just UI > behaviour then probably no need to mention it at all. > > Regards > Andy > > > > >-----Original Message----- > >From: [email protected] [mailto:[email protected]] > On Behalf > >Of Francois Audet > >Sent: 14 July 2009 22:28 > >To: Alan Johnston > >Cc: [email protected] > >Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select > > > > > >> I changed "select" to "select/seize" globally in the > document. I'm > >> not sure it helps readability, but I think we need both terms. > > > >Here is an explanation what I meant with "seize" versus "select". > >I might have been using a definition of "selection" that is > different > >from what you had in mind. > > > >In my mind, I was equating "seizing" with the concept of actually > >reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the > >Appearance agent of the call state "premptively". > > > >In contrast, I was using the term "selection" to mean the > local action > >(on the phone) of choosing which "line" to use (i.e., the "From" > >header). This is local because it does not require any > publication of > >state to the appearance agent. The user presses a line key, no > >signalling comes out immediately (and user probably hears > dial tone). > >When the call is eventually made, it uses that line that was > "selected" > >as the originator (i.e., the From header). > > > >I am proposing that if we use these definitions, then it > makes it much > >clearer throughout the document what we are talking about. There are > >lots of cases where we mean "selection or seizing" (because the > >PUBLISH/ SUBSCRIBE is optional), and in other cases, we > really mean the > >"seizing". > > > >So, for example, in 10.4, messages F1-F2 are actually a > "seizing", not > >merely a "selection". > > > >Anyways, just think about it. > > > >I think there are people who would want to implement the > "line seizure" > >concept, and people who would NOT want to implement it. If > it's clear > >what "seizure" means, then it makes it obvious in the text > what is the > >optional part. > >_______________________________________________ > >BLISS mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
