Re: [Sipping] SIP Subscription for SCADA/Stock quotes

[Adam Roach <[e-mail]>]

Samir Srivastava wrote:
> If my recollection of arguments on the list is correct, There were
> arguments that most of the startups die because of indigestion etc. SIP
> is not an infant any more. In the startup mode, you focus on the problem
> at the hand. But you keep architecture open such that it can handle
> varying needs. It should increase the degree of pervassiveness in the
> future seamlessly. I think fathers/god father of SIP were not be having
> such a myopic vision on the utility of SIP for just mimicking PSTN and
> Presence as you are trying to say. Presence came later and it fit in
> well. 
>   

Having been deeply involved in the whole genesis of events and presence, 
I can confidently say that this is highly inaccurate revisionist bunk.

Forgive me as I indulge in a bit of personal anecdote.

When Jonathan et. al. dropped the first version of the documents that 
would become the presence and instant messaging extensions using SIP, I 
was in Stockholm helping Ericsson's 3GPP delegates cope with the then 
very recent decision by 3GPP to use SIP as their protocol for the IMS 
core. (At that point in time, the only people doing standards work 
within Ericsson who had any familiarity of SIP were me and Sean Olson). 
I recognized the impending train wreck between the use of 
SUBSCRIBE/NOTIFY for PINT and SUBSCRIBE/NOTIFY for what was then IMPP, 
and decided that what we really needed was an extensible framework that 
would allow different usages of these primitives peacefully co-exist. 
Thus was born the draft that eventually became RFC3265. (Ironically, my 
own interest in the problem stemmed partially from the need for a 
call-completion service [1] -- a topic still generating considerable 
consternation).

So, important and relevant point #1: the use of SIP for presence 
preceded a general framework for event notification by several weeks.

(If you would like to verify the timing of a SIP architecture in the IMS 
core, I'd advise starting with S2-00751 [3], dated May of 2000, which I 
wrote during my stint in Stockholm: you will be unable to find anything 
resembling a coherent SIP architecture in any form within 3GPP prior to 
this contribution).

> To me, your fear comes from the arguments given by others for weakness
> of SIP as "SIP Does many things for many people" . I counter it "IP does
> the same", It depends on how you see and design the versatile /
> pervassive protocol fulfilling different needs seamlessly with little
> extensions where processing intelligence of those extensions is just at
> the required end point. Rest nodes are just conduit. To me, Presence in
> its current form is just one aspect. SIP in the core is excellent
> protocol but with some rough edges coming from mimicking PSTN, etc...

The importance of the 3GPP aspect of this story is as follows: until 
3GPP got into the business of extending SIP and defining network 
architectures for it, it was as decidedly un-PSTN-like as possible.

In fact, there was a rather constant thunder of complaining from the 
ITU-T wonks ("Bell Heads", if you will) that the way SIP did things was 
so very, very different than the way ISUP and H.323 did things, and that 
interworking the networks would be problematic. You can see echoes of 
the SIP community's response to this in 
draft-sparks-sip-service-examples-00 [2] (which the Bell Heads 
completely missed the point of, considering it to be the equivalent of 
H.323's annexes as opposed to a thesis on why service standardization 
was unnecessary) and the PSTN interoperation work which was eventually 
published as RFC 3372 and RFC 3398.

So, important and relevant point #2: no one was trying to make SIP mimic 
the PSTN at the time RFC 3265 was developed; reality was quite the 
opposite: "the SIP way" was so thoroughly anti-PSTN that it received a 
steady stream of criticism for not fitting neatly into the Bell Heads' 
view of the world.

Beyond these points of fact, there are a number of points of philosophy 
that I could raise in objection to a lot of what you say (e.g., yes, a 
lot of things run on IP -- this is a very deliberate design that is 
intended NOT to be mimicked in higher layers; google "Internet 
Hourglass" [4] for myriad explanations), but I'll leave the rest of 
those points to others.

/a

[1] http://www.potaroo.net/ietf/idref/draft-roach-sip-acb/
[2] http://tools.ietf.org/html/draft-sparks-sip-service-examples-00
[3] 
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/drafting_meetings/00_05_Stockholm/S2_key_issues/tdocs/S2-000751.zip
[4] http://www.google.com/search?q=%22internet+hourglass%22

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP