Subject: Re: CLOSE, UNSXXSCRIBE, EXPIRE

From: [email-masked] (Igor Faynberg)
Date: Wed, 15 Sep 1999 12:30:29 -0400

Sorry, my previous message got garbled... I am re-sending it:

One question: Why not have UNREGISTER for REGISTER, UNSUB'SCRIBE for
SUB'SCRIBE, and UNDO for DO?  CLOSE seems to be a perfect match for
OPEN (if OPEN is ever to appear).

And why are we trying to minimize the number of methods?  Usually, this would
lead to terrible overloading of those that remain, which, in turn makes
things very hard to learn and comprehend. Kernighan & Ritchie have
emphasized this point in relation to shell programming, but we are dealing
with exactly same thing here! My training and experience have taught me that
having 20 clear commands is much better than one command with tons of
convoluted parameter combinations. On this I do have a strong opinion, although
I by no means insist that it be accepted.

Anyway, please do not apologize to me for arguing with me--I strongly
believe that the final decision belongs to the editors. The only reason
I have offered my view was because I thought it would help to CLOSE the
work on the draft before the last call is to EXPIRE!  My suggestions intended
to resolve a methodology (rather then substance) conflict because there is
NO substance conflict anyway.

Now, in order to progress, I suggest the following:

1) Can we agree on assigning a name to a terminating method so as to match 
the one that opens the activity? Since this is a more general and really SIP 
issue, I would like to hear a response from SIP authors on that, too. (I thought
that Scott, in his last response, wanted to have EXPIRE to terminate at least
two methods, which prompted me to ask whether we really NEED to minimize the
number of methods. If we don't, I believe my proposal addresses Scott's
concern.)

If there is an immediate and clear agreement on that by ALL, let us then
use UN* to match *, EXPIRE to match COMMENCE, etc., and update the draft
appropriately and GET IT OUT THE DOOR.

If there is no agreement--regardless of the reason, then 

2) Anyone who disagrees with 1) MUST produce a specific proposal that would
address ALL the issues raised previously. Subsequently, anyone who would
raise an issued with the latest proposal would need to create a new proposal 
that would address not only the new issue but also ALL other issues. 

I really hope that we will be able to converge on the solution after two
or three iterations. If not, I will arrange a conference call for those
who are interested in discussing this matter.

Again, as long as there is no outstanding technical problem, the issues
of style are to be resolved by the editors only. (That means that if Scott
disagrees with me, things are to be done HIS way!)

With many thanks to all participants for the high-quality discussion,

Igor the Humble

---------
This message came from the IETF PINT Working Group Mailing List.

---

From: Scott Petrack <[email-masked]>
Date: Wed, 15 Sep 1999 19:51:41 -0400 (EDT)

UNSXXSCRIBE it is.

I suppose that we will save EXPIRE to be the counter part to INHALE.
Or maybe to "GETALIFE".... I am sorry to have been obstinate.

Scott

---------