Ok, I think we are on the same page then. I was thinking something along the lines of having a "terminology section" (like most drafts) including something like:
Seizing: An appearance can be seized by communicating an artificial state of "trying" prior to actually initiating a dialog, in order to appear as it was already initiating a dialog. Selecting(or Not-Seizing): An appearance is merely selected (i.e., not seized) if there is no such communication of artificial state of "trying" prior to initiating a dialog: i.e., the state is communicted when the dialog is actually initiated. I'm not attached to using the term "selected". I would just like the distinction to be clear so when developpers read the procedures (and more importantly the example), they know which parts are optional. It's perfectly fine with me if at the end of the day, a phone can be described as "Support Appearance Seizure: yes or no" instead of "Appearance: Seizure vs Selection". > -----Original Message----- > From: Hutton, Andrew [mailto:[email protected]] > Sent: Thursday, July 16, 2009 09:18 > To: Audet, Francois (SC100:3055); Alan Johnston > Cc: [email protected] > Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: > Seize vs Select > > Hi All, > > See below. > > Regards > Andy > > >-----Original Message----- > >From: Francois Audet [mailto:[email protected]] > >Sent: 15 July 2009 17:19 > >To: Hutton, Andrew; Alan Johnston > >Cc: [email protected] > >Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: > >Seize vs Select > > > >I disagree. I think we need some clarification. > > > [Andy H] OK Clarification is always a good thing. > > > >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. > > > > [Andy H] I Agree. > > >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). > > > > [Andy H] I Agree. > > >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. > > [Andy H] I Agree. > > > > >(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". > > > > [Andy H] I agree except that I object to is any discussion about line > selection as we will not be able to agree on what is meant by a "line" > we went over this many times already it is an an appearance > index which > is "seized" or "not siezed" and not a line which many people relate to > an AOR. > > > > > > > > > >> -----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
