RE: [Sip] INFO considered harmful

["Dean Willis" <dean.willis@softarmor.com>]

> > 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?


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.

> 
> > 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.
> 
> 
> > INFO also needs a blob-describing-and-encoding framework, 
> so that the 
> > various uses of INFO can, as appropriate, be effectively documented 
> > and negotiated.
> 
> 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.

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).

> 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.

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

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip