Subject: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00

From: "Dean Willis" <[email-masked]>
Date: Mon, 13 Jan 2003 20:21:45 -0600

It only seemed appropriate to follow up my previous assumably eloquent but
frequently misspelled exhortations by following my own advice and "sending
text".

The resulting draft has been submitted to the archive and should be
announced in due course. In the interim, you may wish to retrieve it from:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.html

or

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.txt

Or, if you just LIKE looking at XML source or wish to fix some of my
probable glaring errors,

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.xml

I'd like to caveat that this is a rough first draft -- I just sat down and
banged it out this afternoon, and only Adam Roach has seen any of it so far,
and that was in small bits.

thanks

--
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: "Frank W. Miller" <[email-masked]>
Date: Tue, 14 Jan 2003 09:44:50 -0500

Looks like a good compromise.

FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Network, Inc.
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jan 2003 18:01:24 +0200

Hi,

To negotiate what INFO can be used for between nodes is good thing, and at least
on a theoretical level it solves one issue.

But, is the biggest problem we have today end-nodes receiving INFOs with data
they don't know to handle? And, how is this going to solve the problem of having
people using INFO for whatever purpose? All they have to do is to define a
package for their who-knows-what data, right? Or, does defining a package allow
one to use INFO for whatever he/she wants?

Or, do we accept Henning's rule about the "bad guys", and do NOT try to define
any rules on exactly what kind of data INFO should be used for in the first
place?

I am not saying that this draft should solve anything, but I would like to know
exactly which issues regarding INFO we are going to try solving :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Jan 2003 11:23:43 -0500

> on a theoretical level it solves one issue.

It would be nice to motivate how this differs and intersects with the 
Content-* indication and negotiation mechanism. After all, if INFO 
transports objects that are opaque to the "SIP layer" (e.g., session 
state), the logical indication of use is via the various Content-* 
indications.

> one to use INFO for whatever he/she wants?

Beyond ISUP and maybe DTMF, what is INFO used for today, by both the 
good and bad guys? What proposals are out there? Last time this was 
discussed, the list seemed pretty short. I think we agree that DTMF has 
better, non-INFO solutions.

With events, we have a whole set of examples and applications to draw 
on. Building a mechanism on an example space of one seems a bit dangerous.

> any rules on exactly what kind of data INFO should be used for in the first

I do think it would be helpful if this draft or some other draft 
indicated where SIP INFO *may* be appropriate. As discussed, this seems 
to involve things where SIP routing and proxies are needed or useful, 
for example.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 Jan 2003 12:57:31 -0600

> To negotiate what INFO can be used for between nodes is good 
> thing, and at least on a theoretical level it solves one issue.
> 
> But, is the biggest problem we have today end-nodes receiving 
> INFOs with data they don't know to handle? 

Well, the "I don't know what this means" problem is really there. SIP-T
basically requires configuration to "know" that the other end understands
and wants ISUP. That's a little bit clumsy.

> And, how is this 
> going to solve the problem of having people using INFO for 
> whatever purpose? All they have to do is to define a package 
> for their who-knows-what data, right? Or, does defining a 
> package allow one to use INFO for whatever he/she wants?

Welll, this draft basically induces the same sort of review process that is
in place for P-headers and event packages -- to get a registered
info-package "name", you have to document this usage as an RFC (any track)
that receives expert review from SIP. The goal here is to help make sure
that anything widely deployed is at least documented in a reasonable
fashion.

My basic philosphy is that if something is going be be a kitchen sink, we
should at least make it a sturdy kitchen sink, try to keep it from getting
plugged up with garbage, and establish some communications between the users
of the sink.
 
> Or, do we accept Henning's rule about the "bad guys", and do 
> NOT try to define any rules on exactly what kind of data INFO 
> should be used for in the first place?

Personally, I don't really care what kind of data INFO gets used for. Market
reality is going to shape the usages towards "stuff that works" -- for
example, I believe the world has realized that using INFO for floor control
over 3G wireless networks just doesn't work. But somebody had to try it
before we really knew.  It seems to me that INFO is reasonably useful
wherever one needs to send application data along a relationship path
established by a SIP dialog, AND that data has no particular relationship
with the SIP state machine, AND the timing, load, and capacity
characteristics of the SIP network are appropriate for that sort of
application. People will probably come up with some downright weird usages.
Some may work. Some probably won't. But as long as they don't step on each
other, they're probably only hurting themselves. This draft (like the
congestion safety work) is about keeping people from stepping on each other.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 Jan 2003 13:55:03 -0600

> state), the logical indication of use is via the various Content-* 

I'm not sure I understand this. Are you saying that we could replace INFO
usage with a Content-Indirected MIME type?

> better, non-INFO solutions.

Well, people have also used or mentioned using INFO for 

* conference control (instructing a conference server to add and delete
legs)

* floor control in a conference bridge (which has timing issues for 3G)

* gaming applications (like transmitting chess moves in parallel to a voice
call)

* pushing user interface components, like data entry forms, keypad layouts
(kpml type stuff), and java applets

* delivering SOAP

* delivering vCards

* delivering calendar data

Some of these are probably bogus. Others may be better-implemented other
ways. All, if implemented usingINFO, could benefit from negotiation (Does
the other guy SUPPORT sending chess moves?) and documentation (Does she mean
the same thing I mean when I send her a application/xchess INFO . . .

--
dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Jan 2003 15:28:59 -0500

> usage with a Content-Indirected MIME type?

No. We currently negotiate above-SIP content with Content-Type, 
Content-Language and all the other Content-Headers, just like HTTP, SMTP 
and other MIME users. If the body contains message/isup, it is an ISUP 
message. It is not clear to me what value an additional, semi-orthogonal 
negotiation mechanism offers. (Semi-orthogonal, since most INFO types 
will have exactly one valid Content-Type.)

> the same thing I mean when I send her a application/xchess INFO . . .

It seems that the meaning should precisely depend on the content type 
and the content disposition.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 Jan 2003 17:40:04 -0600

> could replace 
> > INFO usage with a Content-Indirected MIME type?
> 

Ah. Actually, that is the direction that I initially started taking things
in the draft -- basically, I associated MIME content-types with usages, and
didn't have the Info-Type. Then I briefly talked it over with Adam, and he
talked me into the separate semantic indicator. 

I believe that the assertion that "most INFO types will have exactly one
valid Content-Type" is the breaker. Let's look at text. Is the text I just
sent you indicative of a move in the chess game we are playing? Is it
something I want you to post on a web page for me? Should you just read it?
Is it a javascript that you should use to remap your keyboard? Is it C code
that you should compile and execute? Is it a credit card number that you
should debit for the price of this call? Why the heck AM I sending it to
you? 

There are probably much better examples, but I think that a one-to-one
mapping between content-type and expected function is more constraining than
the way I think people are trying to use INFO, perhaps overly constraining.

--
dean

---

From: "Adam Roach" <[email-masked]>
Date: Wed, 15 Jan 2003 17:32:17 -0600

From: "Henning Schulzrinne" <[email-masked]>
> will have exactly one valid Content-Type.)

Not so sure about this. To take your example, we already have proposals
for application/isup and application/vnd.sentito.isup-text (or whatever
draft-miller-sip-isup-annex-00 plans to propose).

/a

---

From: "Adam Roach" <[email-masked]>
Date: Wed, 15 Jan 2003 18:02:25 -0600

"Henning Schulzrinne" <[email-masked]> writes:

> We currently negotiate above-SIP content with Content-Type, 
> negotiation mechanism offers.

Upon further reflection, I realise that my previous response addressed
the wrong half of this objection (multiple content types per application,
instead of multiple applications per content type).

Take, for example, the content type of "image/jpeg".

It is quite conceivable that someone might define an INFO
package of "app-icon" that uses "image/jpeg" to send
a 32x32 pixel image that should be used as the icon for the
application for the duration of the session.

It is also completely beleivable that someone else might
define an INFO package of "set-pointer" that uses "image/jpeg"
to send a 16x16 bitmap that is to be used as the mouse pointer
when said pointer is in the window associated with the
application.

Now, I'm not advocating these usages of INFO or even the
ability to do either of these things with SIP, but I'm certain
that you will agree that these are the *sort* of content-type
collisions that you will encounter if you don't have the
orthagonal mechanism that Dean includes in his draft.

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Jan 2003 03:35:52 -0500

Consider the interaction with Content-Disposition.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 25 Jan 2003 00:33:23 -0500

The point I have been trying to make all along here is similar to what 
Henning is saying. Everything in this draft can also be done with the 
Allow mechanism, and then you use the method registry for "usages".

Now, Dean has argued that this is somehow fundamentally different due to 
some perceived software layering problem in implementations, but 
functionally speaking, its the same.

THis is what I mean when I have been saying "INFO has no semantics, 
whereas rfc3265 does". There is protocol functionality provided by 
SUB/NOT, independent of any package, and above rfc3261, which makes it 
useful. Not so here.

-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