Subject: Re: PIN BOF

From: [email-masked] (Igor Faynberg)
Date: Mon, 5 Apr 1999 14:42:56 -0400

Scott Petrack wrote:

>But I am going to annoy you as usual, I'm afraid:

Scott,

You have NEVER annoyed me! I have thoroughly enjoyed every piece of 
correspondence we have exchanged and every conversation we had. I very
much respect you for your deep analysis of any subject you undertake, and
your contribution to PINT alone is owesome. With the information haos we are
in, we are bound to be lost in one or another misunderstanding, so I will do
anything I can to resolve it.

>So my point is that in either case, the sending of notification was
>preceeded by some explicit REQUEST that the notification be sent under
>certain conditions. 
>
>Whether the request comes from the same entity that actually receives the
>notification is a technical detail (of course an important one for
>scaleability, etc.) Whether the request is for a "static" notification
>(i.e. independent of any particular call) or "dynamic" notification (i.e.
>for the one call only), is also a technical detail (equally important, of
>course). 
>
>What is important is that in all of these scenarios there is some REQUEST
>for notification that comes in, and this request somehow "knows about" and
>indeed "designates" the entity which is to receive the request, should it
>ever come.

Well, but the point I am trying to make is that "REQUEST" is hardwired. So,
I would argue that this is not a request after all. But I don't want to harp
on it.

>
>This is very different than what happens in, say, a Mail server, or a Web
>server. These are servers that just sit around all day waiting for random
>requests to come in. They advertise themselves via various directory
>services, but the things that send them requests were never ever requested
>to do so by any protocol element.
>

Right!  And this is precisely why I wanted to separate the notifications
mechanism that you and Lawrence developed for PINT from what is to
happen in PITs (sorry, PIN).

In PINT, this is PURELY a SIP issue. IN PI..., I argue, there is no
requested notification. The SCP/Executive System/PI... Client conglomerate
STARTs the service. If the Request/Notify system is to be used, it is to
be used on the PI... Server--which is in the Internet. So, I really think
we would be in full agreement, if I could only get this point across:
the PI... client is sitting in the PSTN. Thus, PSTN starts the PI... services.
But starts them with what?  With the SIP INVITE and a few parameters that
are specified by the respective trigger. And yes, the INVITE messages that
this PI... client is to send "are never ever requested... by any [Internet]
protocol element"!

>
>Of course, there are many things lacking, like how to describe the
>triggers themselves. 

With that I absolutely agree. I sort of see here the name of the trigger
and the parameters (like calling party number--for ICW, or request for the
call redirection number). I think, if we look at specific services, we
will have a better idea. For sure, once the services are described 
sufficiently, we could decide what is needed for these services. 

Respectfully,

Igor

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