Subject: Re: PSTN Interworking Draft

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Jun 1999 11:37:04 -0400

I strongly disagree with the notion of having *-NOTIFY and *-SUBSCRIBE.
This is the road to Babylon. The subscription mechanism should be the
same, the "what's subscribed to" should be part of either headers or
payload, depending on the circumstances. It would be useful if people
take a look at PINT to see if it fits a reasonable, generalizable
subscription model. If not, PINT should be changed before it's too late.

Igor Faynberg wrote:
> 
> Adam Roach wrote:
> 
> >
> To avoid further confusion, reference to the other two other
> drafts should be made, with a note that neither are sufficient
> for the purposes of DTMF information transmission. The 01 version
> of my draft will reflect these changes.
>                                                                                 >
> 
> Adam,
> 
> Thank you for your understanding and for quick reaction to Lawrence's
> note.  I think you correctly point out that the key-words are overloaded;
> I think a solution to that is simply to use keywords that are different
> than the ones that have been spoken for already.  The matter of fact is
> that SUBSCRIBE/NOTIFY statements that have already been agreed on as
> SIP extensions for PINT do have specific semantics, including the sequnces
> in which they appear.
> 
> If you believe that the same mechanisms can be used elsewhere to do
> something else (i.e., DTMF transmission), you should ensure that whatever
> solution you propose is backward compatible. If you believe that the
> mechanisms may not be used (which is what I believe you are saying), the
> best thing would be to use different names. For example, in the case of
> DTMF, it would perhaps be appropriate to use DTMF-SUBSCRIBE, DTMF-NOTIFY.
> 
> I reailize that my proposal may be controversial. Ever since Unix shell
> was introduced, some people thought it was great to have ONE shell script
> with hundreds of parameters covering ALL possible cases. Others argued
> that remembering such parameters and--especially--remembering the combinations
> of them that correspond to one or another specific usage is impossible and
> to learn the usages is very hard. It would much better to have several
> different shell procedures, each having its own set of necessary and
> sufficient parameters. This makes both the design and use unambigous. If
> you change something, you know that the impact of your change is localized.
> 
> So, Lawrence and I do belong to this "don't overload" club, and we heartly
> welcome you to join it!
> 
> Respectfully,
> 
> Igor Faynberg
> 
> ---------
> This message came from the IETF PINT Working Group Mailing List.

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

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 30 Jun 1999 12:06:53 -0500 (CDT)

>SIP extensions for PINT do have specific semantics, including the sequnces

As I understand it, the PINT group is using the SUBSCRIBE and NOTIFY
methods at the suggestion of Henning Schulzrinne. Unless my memory 
has failed (and I don't claim that it hasn't), he and Jonathan
Rosenberg had already published a draft based on these methods at that
time. SUBSCRIBE and NOTIFY have always been meant for further extension.

>solution you propose is backward compatible. 

I made an attempt to allude to this in my previous note, but apparently
failed: I am not authoring a draft for DTMF transmission. I am aware
of the work of others who are doing so. I beleive their mechanism
for doing so will involve SUBSCRIBE and NOTIFY. Since the authors
of this draft have not, to my knowledge, publicly identified themselves
as pursuing this work, I hesitate to do so on their behalf.

Nonetheless, have faith that, in the unlikely event that the
proposed extensions are in conflict with existing work, they will 
quickly be adjusted so as to not interfere.

>So, Lawrence and I do belong to this "don't overload" club, and we heartly

Unfortunately, you're a bit late in the game to effectively weigh in on
this topic. SIP's proposed extensions are rife with examples of messages 
serving multiple purposes, many written by the authors of the original
draft. This is the primary method currently used for extending the
protocol. I discovered some time ago that the introduction of new
method names is met with great resistance (and I have since come to
believe that there is some justification for this).

I want to emphasize that I don't necessarily think your concerns are
unjustified, and I do beleive that they will be addressed by the MMUSIC
group. My point is that your proposed solution is contrary to the 
informal design philosophy that has been established for SIP through 
existing drafts.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---------

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 30 Jun 1999 12:30:41 -0400

There is going to be a new draft soon, but this will beef up only the security
section. (It is likely to come right after the IETF meeting, with the intention
of going for the last call.) As far as SUBSCRIBE/NOTIFY mechanism is concerned,
it has been much discussed and virtually unchanged for a while.

[For reference: The PINT SUBSCRIBE/NOTIFY mechanism was discussed at the last
PINT meeting (in Florida) at length, and it was agreed that PINT needed those
mechanisms as presented, and that they were not part of SIP specification then.]

So, to follow Henning's call, please take a look at the latest draft 
on the PINT page. Henning is absolutely right in that the discussion of any
topic can be reopened (although, based on the stability of the material a few of
us have proceeded with the implementations...)

Igor

Henning Schulzrinne wrote:
> 
>...It would be useful if people