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

From: [email-masked]
Date: Wed, 15 Jan 2003 09:26:53 +0100

Henning,

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

Like for ISUP, ECMA is also in the process of defining the use of INFO for 
QSIG.

Regards,

Frank

_______________________________________________
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: "Eric Burger" <[email-masked]>
Date: Thu, 30 Jan 2003 10:44:40 -0500

If this goes forward, I would also suggest that wording to the effect of "INFO packages MUST describe congestion control mechanisms, or why congestion control mechanisms will not be an issue (e.g., we're talking about only ever sending a single, small message)".

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, January 13, 2003 9:22 PM
> To: [email-masked]
> Subject: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00
> 
> 
> 
> 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-infopac
> kage-00.html
> 
> or
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopac
kage-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

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 30 Jan 2003 10:44:40 -0500

[Lot's of discussion; I'm just catching up.]

The whole issue of 'what this message means' versus 'what this object is' was dealt with to great extent in the VPIM work group.

Adam gave the excellent example of "what does image/jpeg mean?".  We grappled with "what does audio/basic mean?".  The answer is you absolutely cannot determine what the message context (meaning) is from the types of bodies in the message.

Moreover, registering lots of application/mumbles doesn't work either.  There is little value to registering a bunch of things that have the same semantics.  That also has interaction with things like multipart/alternative or multipart/mixed.

You can find a *very* detailed explanation of this problem, and the solution, in RFC 3458.

> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 7:02 PM
> To: Henning Schulzrinne; Dean Willis
> Cc: 'Christer Holmberg'; [email-masked]
> Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00
> 
> 
> "Henning Schulzrinne" <[email-masked]> writes:
> 
> > 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.
> 
> 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: "Eric Burger" <[email-masked]>
Date: Thu, 30 Jan 2003 10:44:40 -0500

Don't worry: your existing SIP-T implementations will still work.  They won't ask for or accept the info-package offer, which means that raw INFO should still work.

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 10:36 AM
To: 'Henning Schulzrinne'; Drage, Keith (Keith)
Cc: 'Dean Willis'; [email-masked]
Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00

I really agree with Henning's viewpoint.  The mechanisms are already there.  Quite frankly, I don't want to have to redo my SIP-T implementation of INFO unless a really good case can be made for it.
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Wednesday, January 15, 2003 10:13 AM 
> To: Drage, Keith (Keith) 
> Cc: 'Dean Willis'; [email-masked] 
> >>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 
> 
> The mistake would be specifying all of them as text/plain. 
> They should 
> be specified as the correct media type to begin with. After 
> all, I may 
> want to save the content and saving a C file as .txt instead of .c is 
> not very helpful. 
> 
> If this is application data, it should be labeled as 
> application/chess. 
> 
> In addition, there is Content-Disposition to look at. 
> 
> 
> >>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 
> >> 
> >> 
> >>Use [email-masked] for questions on 
> current sip Use 
> >>[email-masked] for new developments on the application of sip 
> >> 
> > 
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip 
>