Subject: RE: [Sip] INFO considered harmful

From: "Dean Willis" <[email-masked]>
Date: Fri, 3 Jan 2003 17:15:25 -0600

> The big huge difference I have been trying to point out is 
> that EVENTS 
> DEFINES SEMANTICS, whereas INFO doesn't.

No, EVENTS doesn't define semantics. Event PACKAGES define the semantics of
particular instances of the event methods. All that 3265 gives us is
subscription to and notification of otherwise undefined blobs, and a
framework for defining event packages. It is up to a specific event package
to define a specific blob, including how it is named, how it is encoded, and
what it means. And one of the interesting things is that 3265 and sipchange
establishes a lower threshold-of-review over event packages (which are NOT
considered protocol extensions) than for new SIP methods (which obviously
ARE protocol extensions).

INFO also needs a blob-describing-and-encoding framework, so that the
various uses of INFO can, as appropriate, be effectively documented and
negotiated. 

--
Dean

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 05 Jan 2003 21:28:21 -0500

Dean Willis wrote:
> No, EVENTS doesn't define semantics. 

Of course it does. There are lots of MAYS, MUSTS and SHOULDs in there. 
There is behavior dealing with subscription refreshes, rules on when to 
send NOTIFY, and so on and so on. How can you say that none of those 
qualify as semantics?

> Event PACKAGES define the semantics of
> particular instances of the event methods. 

Within a well defined framework. 3265 defines clear rules on what each 
package has to specify, and what it can and cannot due ontop of rfc3265.

> various uses of INFO can, as appropriate, be effectively documented and

Well, I'll try one more time, since I am clearly not getting my point 
across.

RFC3265 defines semantics above and beyond RFC3261. All of those 
MAY/MUST/SHOULD I was talking about. If you had a choice between 
defining a new package, and defining your own sub/not mechanisms, it 
would be a LOT more work to define your own sub/not mechanisms.

Not so for INFO. WHen deciding whether to specify an INFO usage, or a 
new method, there is no additional work to do (specification-wise) when 
specifying a new method as opposed to a new INFO usage. To me, that 
means that INFO is devoid of semantics.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 8 Jan 2003 16:54:53 -0600

> send NOTIFY, and so on and so on. How can you say that none of those 

That's called a "protocol specification", not a specification of the
semanticsd of the delivered content.

What does a NOTIFY mean? Does it mean that I have voice mail and I should
poll it? Does it mean that somebody has subscribed to my presence and I
should adjust my authorization policy? Does it mean that my laundry is done
and I should go pick it up? Does it mean that the IRS is going to audit my
books and I should flee for the border?  

You can't answer this question, in general, because those semantics are NOT
defined in RFC 3265. They're defined in event packages.

Similarly, we complain because the INFO spec doen't tell us what an INFO
means. Should we convert the body to ISUP? Should we execute the operator
now? Should the phone explode? The INFO spec should no more answer this than
does the Events spec. The semantic encoding is a separate problem.

Now, here's the difference. I don't think you're talking about the presence
of semantic information. I think you're talking about the absence of a
mechanism for documenting the semantic information. Event packages give us
this mechanism for events. We don't have anything like that for INFO. You're
not talking semantics -- you're talking tools for exchanging meta-semantics.

> > various uses of INFO can, as appropriate, be effectively documented 
> > and negotiated.
> 

huh?

It would be much more work to independently reimplement the functionality of
INFO than it is to encode some information into MIME and ship it via INFO,
especially given that the main functionality of INFO is correlated
resolution with an existing dialog (identical rendezvous).

> means that INFO is devoid of semantics.

No, it just means that the process for defining a new INFO usage is broken.

--
Dean