Subject: [Sip] INFO Framework

From: Eric Burger <[email-masked]>
Date: Wed, 19 Nov 2008 18:44:27 -0600

Consensus stuff:

1. Remove Send-Info. It takes away a bunch of race conditions. The  
value of having it is theoretical. We can always add it in later, so  
we will keep the header name "Recv-Info".

2. Remove Contact: header from INFO table

3. Remove Recv-Info from INFO table

4. Mention what happens when you forget the Recv-Info header when you  
refresh a dialog

5. Only one Info Package body in the INFO method request. However,  
implementations MUST support multipart, per RFC 3261 as updated by  
body-handling.

If you disagree with these items, squeak now.  Send us an INFO.

_______________________________________________
Sip mailing list  https://www.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: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 14:19:25 +0100

Hi,

I probably missed it, but what is the justficiation for only one Info
Package body per INFO request?

Didn't we discuss it earlier, and came to the conclusion that it
wouldn't add any extra complexity?

...especially, as you say, one MUST support multipart anyway.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Burger
Sent: Thursday, November 20, 2008 2:44 AM
To: SIP List
Subject: [Sip] INFO Framework

Consensus stuff:

1. Remove Send-Info. It takes away a bunch of race conditions. The value
of having it is theoretical. We can always add it in later, so we will
keep the header name "Recv-Info".

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 14:57:37 +0100

Hi, 

>1. Remove Send-Info. It takes away a bunch of race conditions. The
value of having it is theoretical. We can always add 
>it in later, so we will keep the header name "Recv-Info".

Could someone explain those race conditions to me, or point to a thread
where they are described?

In SDP o/a, for example, I think the advantages of being able to better
describe also what-I-can-send capabilities would be more than
theoretical.

If we don't want to use two headers, we can of course have a single
header with direction parameters.

E.g; Info-Package: dtmf-package;sendonly, isup-package;sendrecv

I think we have historical examples on when adding restrictions,
withoout any really good reason, later causes problems.

Regards,

Christer

---

From: Eric Burger <[email-masked]>
Date: Fri, 28 Nov 2008 08:38:52 -0500

It was a consensus thing, not a technical thing :-)

On Nov 20, 2008, at 8:19 AM, Christer Holmberg wrote:

> value

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 14:48:00 +0100

Hi,

If there is no technical reason I don't see why we again shall make a
restriction which we later may "suffer" from.

Regards,

Christer

---

From: Eric Burger <[email-masked]>
Date: Fri, 28 Nov 2008 08:54:49 -0500

I suffered enough in the meeting room.  Up to you to convince the rest  
of the group.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 12:35:58 -0500

I think I was one of the people at the meeting who argued against it, so I'll talk turkey:

INFO is in wide use today, and it works(!), with barely any interop problems.

IMHO, the requirements driving the INFO packages draft was to solve two specific problems with current INFO:
1) Negotiation/advertisement of INFO uses, so that a UA is not "surprised" when it gets an INFO, and we don't need system configuration for every UA we talk to for what it can do.  Configuration on a system-wide basis is one thing, but configuration per far-end is *really* bad.
2) Indication of what the use is for the INFO message that is sent, so that one can receive the INFO method without ambiguity as to its purpose.

Those are the only things that drove a new draft, AFAIK.  Anything else is basically gravy.

We also had consensus (I think) a while back that the only chance we have to make people use this draft instead of current INFO was to:
a) Keep it simple.
b) Keep it simple.
c) Keep it simple.

So ISTM we don't have room for gravy - we need to focus on slice of the pie that we care about.  We need to keep the weight off the draft by sticking to the meat of the problems being solved, without stuffing in extra capabilities and by skipping the extra portions.  If we pile on more features, and mash in scenarios not covered by current INFO, there's little chance current systems/implementers will digest this thing and we'll end up with a dead duck instead.  So I was one of the people that cried fowl at the last meeting, and suggested we scrape the extras off our plate so we can serve up a draft people can really swallow.  Otherwise they'll continue doing what they're doing now.  We can shop around for more features the day after the draft is done, by putting extras in packages - but having people buy into those is only possible if we make the base draft cheap to implement now.

-hadriel

> Christer Holmberg
> Sent: Friday, November 28, 2008 8:48 AM
>
> Hi,
>

---

From: Eric Burger <[email-masked]>
Date: Fri, 28 Nov 2008 13:15:00 -0500

Oh man! I'm in tryptophan overdose!

On Nov 28, 2008, at 12:35 PM, Hadriel Kaplan wrote:

> 1) Negotiation/advertisement of INFO uses, so that a UA is not  
> "surprised" when it gets an INFO, and we don't need system  
> configuration for every UA we talk to for what it can do.   
> Configuration on a system-wide basis is one thing, but configuration  
> per far-end is *really* bad.
> 2) Indication of what the use is for the INFO message that is sent,  
> so that one can receive the INFO method without ambiguity as to its  
> purpose.
>
> We also had consensus (I think) a while back that the only chance we  
> have to make people use this draft instead of current INFO was to:
> a) Keep it simple.
> b) Keep it simple.
> c) Keep it simple.
>
> So ISTM we don't have room for gravy - we need to focus on slice of  
> the pie that we care about.  We need to keep the weight off the  
> draft by sticking to the meat of the problems being solved, without  
> stuffing in extra capabilities and by skipping the extra portions.   
> If we pile on more features, and mash in scenarios not covered by  
> current INFO, there's little chance current systems/implementers  
> will digest this thing and we'll end up with a dead duck instead.   
> So I was one of the people that cried fowl at the last meeting, and  
> suggested we scrape the extras off our plate so we can serve up a  
> draft people can really swallow.  Otherwise they'll continue doing  
> what they're doing now.  We can shop around for more features the  
> day after the draft is done, by putting extras in packages - but  
> having people buy into those is only possible if we make the base  
> draft cheap to implement now.
>
> -hadriel
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 20:03:43 +0100

Hi,

I agree to both a) and b), and even c) :)

But, my question is still: what makes support of multiple packages
un-simple? Based on the discussions we had on the list before the IETF
meeting, I thought there were no problems.

Regards,

Christer 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, November 28, 2008 7:36 PM
To: Christer Holmberg; Eric Burger
Cc: SIP List
Subject: RE: [Sip] INFO Framework - one pakage per INFO

I think I was one of the people at the meeting who argued against it, so
I'll talk turkey:

INFO is in wide use today, and it works(!), with barely any interop
problems.

IMHO, the requirements driving the INFO packages draft was to solve two
specific problems with current INFO:
1) Negotiation/advertisement of INFO uses, so that a UA is not
"surprised" when it gets an INFO, and we don't need system configuration
for every UA we talk to for what it can do.  Configuration on a
system-wide basis is one thing, but configuration per far-end is
*really* bad.
2) Indication of what the use is for the INFO message that is sent, so
that one can receive the INFO method without ambiguity as to its
purpose.

Those are the only things that drove a new draft, AFAIK.  Anything else
is basically gravy.

So ISTM we don't have room for gravy - we need to focus on slice of the
pie that we care about.  We need to keep the weight off the draft by
sticking to the meat of the problems being solved, without stuffing in
extra capabilities and by skipping the extra portions.  If we pile on
more features, and mash in scenarios not covered by current INFO,
there's little chance current systems/implementers will digest this
thing and we'll end up with a dead duck instead.  So I was one of the
people that cried fowl at the last meeting, and suggested we scrape the
extras off our plate so we can serve up a draft people can really
swallow.  Otherwise they'll continue doing what they're doing now.  We
can shop around for more features the day after the draft is done, by
putting extras in packages - but having people buy into those is only
possible if we make the base draft cheap to implement now.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 14:23:49 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, November 28, 2008 2:04 PM
>

>From a protocol perspective: you'd have to define that more than one package name can be indicated in an INFO, that they have to use cid or some means to identify which body part is which package's, and you'd have to handle the case when the receiver can process one/some package body parts but not another.  It's not truly "free" to add this.  It adds time and complexity to the draft.  For example, what if you received an INFO with two packages of the same package name?  Is that ok?  Which gets processed first?

>From a developer's perspective: you'd have to read a bigger RFC and grok more; and handle more execution paths or at least more logging events/cases and possibly more configuration than your current INFO code.

>From a product perspective: you'd have to test more scenarios in QA, train your support staff on more conditions, and document more logging event cases.

Current INFO use doesn't support this capability, so why do we need to add it?

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 20:38:04 +0100

Hi, 

>
>From a protocol perspective: you'd have to define that more than one
package name can be indicated in an INFO,

Sure. You allow a list of values in the Info-Package header.

>that they have to use cid or some means to identify which body part is
which package's,

Based on the e-mail discussions with Paul, I thought each package was
going to have a unique Content-Disposition value. Has that changed?

But, how is package identified in the case there is only one package,
but still multipart (which you DO say must be supported)?

>and you'd have to handle the case when the receiver can process
one/some package body parts but not another.  It's not truly "free" to
add this.  
>It adds time and complexity to the draft.

Isn't the generic handling of body parts described in the body-handling
spec?

>For example, what if you received an INFO with two packages of the same
package name?  Is that ok?  Which gets processed first?

That's up to the application using the package to decide.

>From a developer's perspective: you'd have to read a bigger RFC and
grok more; and handle more execution paths or at least more logging
events/cases and possibly more configuration than your current INFO 
>code.
>
>From a product perspective: you'd have to test more scenarios in QA,
train your support staff on more conditions, and document more logging
event cases.
>Current INFO use doesn't support this capability, so why do we need to
add it?

AFAIK there is nothing which prevents you to from using multipart with
INFO today, is it?

Trust me, I want all this to be simple, but I also want to be able to
answer when someone asks be why it is not allowed :)

Regards,

Christer

---

From: Eric Burger <[email-masked]>
Date: Fri, 28 Nov 2008 16:34:12 -0500

Multiple packages breaks the easy, 95% case: what if I have only a  
single body part, and it is the Info Package payload? You only get  
Content-ID when you have MIME. We would have to mandate MIME for every  
new Info Package implementation.

Not a pain in theory, but for speed of adoption, I am willing to bet  
most folks with quasi-proprietary INFO usages, like MSCML and MSML,  
would much rather add a single header (Recv-Info) and use all of the  
rest of the SIP machinery they have in place rather than having to  
hack the application.

As far as handling one good and one bad Info Package: that is actually  
a total non-issue (sorry Hadriel).  The SIP stack understands the Info  
Packages by virtue of indicating Recv-Info, there being an Info- 
Package header, and the body being of the correct type. If there is a  
single Info-Package that was not advertised in a Recv-Info, tough: the  
whole SIP transaction fails (the INFO request). If all of the Info- 
Packages are supported, but the contents of one of them is bad, tough:  
the SIP transaction succeeded (200 OK). It is up to the application to  
handle the particular bad package payload. That is 100% identical to  
what the UAS does if it receives a single well-formed, but bad, INFO  
request. Send the 200 OK and let the application sort out the body.   
SIP has done its job - don't be a layer violator and conflate an  
application error with a transport error!

On Nov 28, 2008, at 2:38 PM, Christer Holmberg wrote:

>> Current INFO use doesn't support this capability, so why do we need  
>> to
> add it?
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 22:43:12 +0100

Hi, 

>Multiple packages breaks the easy, 95% case: what if I have only a
single body part, and it is the Info Package payload?

We DO say that one must support multipart, don't we? So, even in the
one-package-only case one needs a way to find that Info Package.

How is that done, and why doesn't that work also for multiple info
packages? That's all I need to know :)

Regards,

Christer

> Isn't the generic handling of body parts described in the body- 
> handling spec?
>

---

From: Eric Burger <[email-masked]>
Date: Fri, 28 Nov 2008 16:51:47 -0500

Again, this is why I said, "technically easy."

However, it mean more package work, which the *work group* (not me)  
said, "hard - please punt."

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 16:54:04 -0500

> Sent: Friday, November 28, 2008 4:34 PM
>

I'm not, at least I don't think so. :)  I said it adds protocol complexity to handle failure of processing of more than one info package body-part in a single INFO.  Why?  Because we would have to specify what order they get processed in, because that may affect what happens in the application layer.  When it's just one package for an INFO, we don't have to say anything.
But anyway that one piece was a minor point. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 16:58:21 -0500

> Sent: Friday, November 28, 2008 2:38 PM
>

I'm not a developer, but ISTM that alone means more code complexity and test cases than a single one, and certainly more than current INFO usage in the wild.

> answer when someone asks be why it is not allowed :)

That's easy: "To keep it simple".

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 23:03:44 +0100

Fine, assume we go for one package only: in the case of multipart, how
do I find the package? 

You have started a separate thread on that, so maybe we can move this
discussion there.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, November 28, 2008 11:58 PM
To: Christer Holmberg; Eric Burger
Cc: SIP List
Subject: RE: [Sip] INFO Framework - one pakage per INFO

> Sure. You allow a list of values in the Info-Package header.

I'm not a developer, but ISTM that alone means more code complexity and
test cases than a single one, and certainly more than current INFO usage
in the wild.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Nov 2008 17:22:13 -0500

Eric,

I don't know if I understand what you are saying. Comments inline.

	Paul

> single body part, and it is the Info Package payload?

If there is a single body part, how do you know it is the Info Package 
payload? If it is a *type* that would be valid as the info package 
payload, that may be circumstantial evidence, but is not a guarantee. 
Certainly the Content-Disposition might have an impact on it, but since 
you haven't defined the use of C-D for info packages, I don't know 
exactly how to treat that.

IMO, if you are going to use a CID reference, then you should *always* 
use a CID reference to define the part, even if it is the only part. If 
you don't want to do that, then I suggest we instead use C-D to define 
the info-package body part, which will then be easy as long as we only 
permit a single info-package.

>  You only get

Are you saying we can't have a Content-ID in the sip message itself, 
applying to the whole body? We allow other Content-* headers in sip 
messages. Its always been my interpretation that a SIP message is a 
special case of a mime message, and hence can have any mime headers.

> rest of the SIP machinery they have in place rather than having to hack 
> the application.

If you want to do it that way, then I suggest we use C-D (with a new 
disposition type) to define the info-package, and make that new 
disposition type be the default CD for INFO messages.

> As far as handling one good and one bad Info Package: that is actually a 
> total non-issue (sorry Hadriel).  The SIP stack understands the Info 
> Packages by virtue of indicating Recv-Info, there being an Info-Package 
> header, and the body being of the correct type. If there is a single 
> Info-Package that was not advertised in a Recv-Info, tough: the whole 
> SIP transaction fails (the INFO request). If all of the Info-Packages 
> are supported, but the contents of one of them is bad, tough: the SIP 
> transaction succeeded (200 OK). It is up to the application to handle 
> the particular bad package payload. That is 100% identical to what the 
> UAS does if it receives a single well-formed, but bad, INFO request. 
> Send the 200 OK and let the application sort out the body.  SIP has done 
> its job - don't be a layer violator and conflate an application error 
> with a transport error!

I don't think I agree with this, but it could stand some further 
discussion. Are you asserting this behavior is special for INFO? Or that 
it is true for all messages?

In the case of INVITE and UPDATE with SDP session bodies, we certainly 
fail the message because of bad SDP syntax or even semantics when the 
type is right. (488/606 responses for example.)

I don't find anything in 2976 that calls for a success response when the 
content of the body is incorrect.

	Thanks,
	Paul

> ------------------------------------------------------------------------
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 29 Nov 2008 00:13:57 +0100

> restriction which we later may "suffer" from.

I think the whole SIP protocol is a good example of how a too much permissive 
design creates more interop issues than a more restricted design.

-- 
Iñaki Baz Castillo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Nov 2008 19:15:22 -0500

I think it defining valid syntax without carefully defining the 
corresponding semantics that is the problem. As long as we define both I 
don't see it as a problem.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 19:16:38 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
> Sent: Friday, November 28, 2008 5:22 PM
>

Hmm... interesting idea.  So define a single, global C-D value like "package", which all packages use?  Wouldn't that limit what a specific package could do? (like how would you get a package that wants render, vs. icon, vs. one which wants signal?)

> content of the body is incorrect.

Yeah there's no debate that SIP expects INVITE/UPDATE to be handled integral with body processing.  What's always been argued is how to handle things like MESSAGE, SUB/NOT and INFO.  Several people have argued the body part content of those was at a higher layer.  The text in SUB/NOT RFC only defined a response code for bad Event-types or unknown body content-types I think, but left body processing failure out of it.  And none of the packages seem to go any deeper as far as I can tell.

Of course in practice some (many?) devices respond with failure codes when body processing fails no matter the method.

Wasn't this debated a couple few ago on this list?

-hadriel

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 28 Nov 2008 18:44:12 -0800

> Wasn't this debated a couple few ago on this list?

I sort of see the logic although I'm also not 100% convinced by it.

In any event (no pun intended) I don't think the draft adequately deals 
with the implications of this model. If errors occurring at higher 
layers aren't reported as failure of the INFO request itself, it pretty 
much follows that the 200 response to the INFO must include a payload 
that carries info (sorry, pun not intended here either) on the error.

The alternatives would be:
1) Don't report app-level errors. Perhaps OK for simple packages.
2) Report outcome in separate INFO requests going in the opposite 
direction. Seems wasteful and requires additional app-level correlation.

AFAICT the draft has no discussion on how to carry app-level success or 
failure indications. In fact, the table in sec 5.2 indicates that 
Info-Package is allowed in requests only.

Assuming an event package specifies that all INFO requests result in a 
response which is carried in the 200 response, what does that mean for 
the info package negotiation? An implementation might be able to act as 
a sender of this type of INFO but not as a receiver. It still needs to 
understand the INFO responses but presumably it needn't list the info 
pkg in Recv-Info header fields it generates.

Just as an FYI ECMA has defined TR/87, a SIP INFO binding for the 
computer-supported telecommunications applications (CSTA) CTI standard, 
which uses exactly that model. CSTA requests and events are carried in 
SIP INFOs and these INFO requests succeed even if the CSTA request 
fails. For CSTA requests the 200 response to INFO always carry a CSTA 
response and for CSTA events the INFO response has no payload. The spec 
is available from 
http://www.ecma-international.org/publications/techreports/E-TR-087.htm.

Thanks,
Anders

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Nov 2008 23:27:34 -0500

inline.

	Paul

P.S. Its a pity that we haven't anything better to do on a holiday 
weekend. :-)

Hadriel Kaplan wrote:
> Hmm... interesting idea.  So define a single, global C-D value like "package", which all packages use? 

Yes, that is what I had in mind.

> Wouldn't that limit what a specific package could do? (like how would you get a package that wants render, vs. icon, vs. one which wants signal?)

If it wants bodies like that, which are processed based on their type 
and disposition, it can just include them for processing in their own 
right independent of the method.

For actual info package bodies, the handling should be determined by the 
  definition of the info package, not by the content disposition. If we 
are identifying the body of the info package via cid, then the c-d of 
the info package should be by-reference as defined in the body handling 
draft.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 23:50:13 -0500

> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Friday, November 28, 2008 9:44 PM
>

No I think the logic that Eric's arguing for is "you asked for delivery of this package, and I'm responding with 200 ok because it was delivered".  In other words treat INFO as a delivery vehicle, like MESSAGE, and as long as the package was delivered you send a 200 ok, with no correlation to if/when the package was opened and read successfully or not by a higher-layer info-package "consumer".

> direction. Seems wasteful and requires additional app-level correlation.

Yeah, I think Eric's argument is for (2).  If they need it, they pay for it.

I don't personally care either way - I'm more interested in knowing if current INFO users *need* to have a 200 ok sent back even on content processing failure.  Because if someone needs it, then we should define it that way; anyone else who doesn't and wants to integrate it into the response can still freely send back a 415 or 488 or whatever to the INFO, because the rules for a UAC would not change and none would be the wiser.

But it does mean all drafts defining a specific package would need to put rules in for how to indicate subsequent failure after a 200 ok if they need to, and that sucks. :(

I'm trying to see what Subscribe/Notify does about this, and grep can't seem to find anything.  I wonder if this was not handled in Sub/Not?

> Info-Package is allowed in requests only.

Right, only in requests.  Failure of the INFO delivery or package-name type stuff would be in this draft as a request failure; whereas failure to process the package contents (ie body content) would be specified by the drafts which define specific packages.  Presumably they would need to specify error indications in reverse-direction INFO requests, or better yet ignore the error if possible.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Nov 2008 00:42:23 -0500

> No I think the logic that Eric's arguing for is "you asked for delivery of this package, and I'm responding with 200 ok because it was delivered".  In other words treat INFO as a delivery vehicle,…

I just reviewed 3428, and I don't read it as saying that a 200 should be 
returned of the message is *received*. It says that the the message 
should be processed according to the rules of sip, and then a final 
response should be returned immediately. It just says the message need 
not be *rendered* immediately (or ever).

It doesn't say that you can't, or shouldn't, check the validity of the 
message and return an error if it is invalid.

> Yeah, I think Eric's argument is for (2).  If they need it, they pay for it.

Certainly that is a possibility, but only for packages that define a way 
to do that.

> I don't personally care either way - I'm more interested in knowing if current INFO users *need* to have a 200 ok sent back even on content processing failure. 

That is a good question. I certainly wouldn't *count* on that behavior 
based on the current language.

> Because if someone needs it, then we should define it that way; anyone else who doesn't and wants to integrate it into the response can still freely send back a 415 or 488 or whatever to the INFO, because the rules for a UAC would not change and none would be the wiser.

Yup. For something like DTMF, I would expect to get an error if the body 
is badly formed, not an info in the other direction.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Nov 2008 00:41:47 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, November 28, 2008 11:28 PM
>

What do you mean?  This is way better than work. :)

> the info package should be by-reference as defined in the body handling

Since any RFC defining piggy-backer bodies need to use CID, is there a reason info-packages have to as well?

Like is this ambiguous for either an info-package or a piggy-backer?:

----BEGIN----
INFO sip:[email-masked] SIP/2.0
Call-ID: [email-masked]
From: <sip:[email-masked]>;tag=27285
To: <sip:[email-masked]>;tag=GR52RWG346-34
CSeq: 2 INFO
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
Max-Forwards: 70
Info-Package: turkey-shoot
Foobar-piggybacker: <cid:[email-masked]>
Content-Length: [whatever]
Content-Type: multipart/mixed;boundary="boundary1"

--boundary1
Content-Type: text/plain

Eat the turkey!
--boundary1
Content-Type: text/plain
Content-Disposition: by-reference
Content-ID: <[email-masked]>

Please don't eat me!
--boundary1--

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Nov 2008 01:14:14 -0500

> Sent: Saturday, November 29, 2008 12:42 AM
>
> Hadriel Kaplan wrote:
>

Oh no of course you *can* check its validity and respond negatively - the question is if you must, or if you can instead return 200 ok even if you couldn't process the content.  I think it was implied in Sub/Not and Message that you could respond with 200 even if you (later) could not actually process the body content successfully.  So for INFO, if we allow you to send 200 even if you can't process the body content, then the packages have to specify what to do in that case (which obviously the package can just say "ignore it, do nothing").

Take DTMF for example - would we require processing before responding?  Or would we allow post-processing?  If the latter, would we need to send an error indication back upstream?  I think we would allow post-processing, but ignore it.  And definitely allow an integrated processing model to return 4xx as well, since that can happen anyway for other reasons.

-hadriel

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 28 Nov 2008 23:03:52 -0800

> Yeah, I think Eric's argument is for (2).  If they need it, they pay for it.

Well, in the case of (2) I'd say they'd be overpaying. In my view it's a 
non-starter. People will want to be able to send app-level responses and 
they won't want to go through a lot of extra trouble to do it. And why 
should they? I'm thinking we should allow app-level errors to be 
signalled with INFO error codes and/or allow INFO responses to carry 
responses along the lines of what CSTA does.

I'll be applying the flame retardant now...

Anders

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 30 Nov 2008 13:15:46 +0100

Hi,

I agree with Paul: it's about documenting stuff in a way so that not only we understand it (eventhough there are RFCs which I am not sure even people on the list fully understands :), but also that others understand it. 

I also think that history also shows that having too much restrictive design can cause problems later.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Saturday, November 29, 2008 2:15 AM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [Sip] INFO Framework - one pakage per INFO

I think it defining valid syntax without carefully defining the corresponding semantics that is the problem. As long as we define both I don't see it as a problem.

	Thanks,
	Paul

Iñaki Baz Castillo wrote:
> I think the whole SIP protocol is a good example of how a too much 
> permissive design creates more interop issues than a more restricted design.
> 
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: Sun, 30 Nov 2008 15:50:43 -0500

Let us try again.

INFO is a method that *transports* Application-Level "messages".

INFO is NOT a method of Application-Level messaging.

What is the difference?  In TCP, if I send a message, "SIP/2.blah  
blech" to port 5060, TCP will acknowledge delivery of that packet.   
That is like a "200 OK" in SIP.  The process monitoring port 5060, on  
the other hand, will hopefully come back with some sort of "4xx you  
suck" message, encapsulated over TCP, which TCP will acknowledge  
delivery of.

It is bad enough that we are proving Oran's Law: any well-deployed  
protocol becomes a transport protocol. Let us not make it worse and  
make SIP look like Bluetooth with its dozens of profiles for whether  
you are a data device, a speaker, a microphone, a headset (yes, which  
is different than a speaker and a microphone), and so on.

Let INFO be INFO: something that *transports* messages through a SIP  
Proxy network.  Note I say "through a SIP Proxy network."  If you do  
not want to traverse Proxies, use TCP :-)

On Nov 29, 2008, at 2:03 AM, Anders Kristensen wrote:

>> No I think the logic that Eric's arguing for is "you asked for  
>> delivery of this package, and I'm responding with 200 ok because it  
>> was delivered".  In other words treat INFO as a delivery vehicle,  
>> like MESSAGE, and as long as the package was delivered you send a  
>> 200 ok, with no correlation to if/when the package was opened and  
>> read successfully or not by a higher-layer info-package "consumer".
> Well, in the case of (2) I'd say they'd be overpaying. In my view  
> it's a non-starter. People will want to be able to send app-level  
> responses and they won't want to go through a lot of extra trouble  
> to do it. And why should they? I'm thinking we should allow app- 
> level errors to be signalled with INFO error codes and/or allow INFO  
> responses to carry responses along the lines of what CSTA does.
>

---

From: Anders Kristensen <[email-masked]>
Date: Sun, 30 Nov 2008 13:44:23 -0800

Eric,

I understand what you're saying but as I said I think it's problematic 
or at least warrants some discussion in terms of where it leads. My 
worry is that it makes it significantly more tedious to build on the 
info-events work and hence invites people to either ignore the whole 
thing or the parts with which they disagree.

So let's take the ubiquitous DTMF example. Someone defines a DTMF info 
event package and they want the recipient of DTMF events to be able to 
indicate to the sender that a particular event could not be decoded. If 
I understand you correctly, the error indication would have to be 
carried in an INFO going in the opposite direction of the DTMF itself.

PROBLEM 1: If errors are to be returned this way it means that both 
parties must signal both "Send-Info: dtmf" and "Recv-Info: dtmf". Hence 
there's no distinction between the sender of DTMF events and the sender 
of responses to DTMF events. Unless the dtmf package is modeled as two 
separate INFO event packages.

PROBLEM 2: In some cases (most likely more often than not) it will be 
necessary to correlate responses to requests. In your model this 
correlation has to be done at the app level, that is, in the INFO 
payload. However, that will make it difficult to use existing formats 
that don't have a convenient place to put such an ID. My employer's INFO 
DTMF payload doesn't have a place to put it.  Another frequently used 
example is the exchange of JPG images for whatever purpose. Again, no 
place to put an app level ID in the INFO payload. You could put it in 
the INFO header put that would be a layer violation, right?

PROBLEM 3: If all events require a response you end up with twice as 
many INFO transactions as is really necessary. That's difficult to 
swallow without a really good reason. We could allow 200 respones to 
INFO to carry INFO package responses with no adverse affects to layering 
so that's not it.

Thanks,
Anders

Eric Burger wrote:
> What is the difference?  In TCP, if I send a message, "SIP/2.blah blech" 
> to port 5060, TCP will acknowledge delivery of that packet.  That is 
> like a "200 OK" in SIP.  The process monitoring port 5060, on the other 
> hand, will hopefully come back with some sort of "4xx you suck" message, 
> encapsulated over TCP, which TCP will acknowledge delivery of.
> 
> protocol becomes a transport protocol. Let us not make it worse and make 
> SIP look like Bluetooth with its dozens of profiles for whether you are 
> a data device, a speaker, a microphone, a headset (yes, which is 
> different than a speaker and a microphone), and so on.
> 
> Proxy network.  Note I say "through a SIP Proxy network."  If you do not 
> want to traverse Proxies, use TCP :-)
> 
> 
>>> like MESSAGE, and as long as the package was delivered you send a 200 
>>> ok, with no correlation to if/when the package was opened and read 
>>> successfully or not by a higher-layer info-package "consumer".
>> Well, in the case of (2) I'd say they'd be overpaying. In my view it's 
>> a non-starter. People will want to be able to send app-level responses 
>> and they won't want to go through a lot of extra trouble to do it. And 
>> why should they? I'm thinking we should allow app-level errors to be

---

From: Eric Burger <[email-masked]>
Date: Sun, 30 Nov 2008 17:28:03 -0500

PROBLEM 1: If you want to receive package Foo, and Foo has asymmetric  
information going the other way, then you want to send Foo-Response.  
Like you say, Foo is not the same as Foo-Response.  Look at KPML as an  
example of how to do this right.

PROBLEM 2: You've got it in one! The correlation MUST be at the  
application layer.  If you have a package that has asymmetric  
information flows, then you have two choices.  The first is that you  
are using a dialog-related application-to-application messaging  
protocol (INFO) because you want to send messages related to *this*  
dialog. Any response belongs to the request. Fairly straight forward.   
Otherwise, if you have a package that is really using INFO for  
tunneling, then it is most likely already doing some sort of  
multiplexing, which means you already need some way of identifying  
what the messages are for and about.

PROBLEM 3: Another winner! If you care at all about performance, you  
would NEVER use INFO!!!!  Come on guys - let's look at DTMF: one to  
sixteen bytes of payload, two thousand bytes of SIP overhead.

Of course, the problems listed below are sort of hyper-theoretical.   
If a UAC cannot get a message as simple as DTMF right, getting an  
error message from the UAS saying the UAC got it wrong is not going to  
help.  I'll bet my next $100 dollars that a UAC that needs hints  
inside of a package to get something as easy as DTMF right will core  
dump when it gets an error.

I feel as if I am swimming upstream with a school of Red Herrings ;-)

On Nov 30, 2008, at 4:44 PM, Anders Kristensen wrote:

> Eric,
>
> I understand what you're saying but as I said I think it's  
> problematic or at least warrants some discussion in terms of where  
> it leads. My worry is that it makes it significantly more tedious to  
> build on the info-events work and hence invites people to either  
> ignore the whole thing or the parts with which they disagree.
>
> So let's take the ubiquitous DTMF example. Someone defines a DTMF  
> info event package and they want the recipient of DTMF events to be  
> able to indicate to the sender that a particular event could not be  
> decoded. If I understand you correctly, the error indication would  
> have to be carried in an INFO going in the opposite direction of the  
> DTMF itself.
>
> parties must signal both "Send-Info: dtmf" and "Recv-Info: dtmf".  
> Hence there's no distinction between the sender of DTMF events and  
> the sender of responses to DTMF events. Unless the dtmf package is  
> modeled as two separate INFO event packages.
>
> PROBLEM 2: In some cases (most likely more often than not) it will  
> be necessary to correlate responses to requests. In your model this  
> payload. However, that will make it difficult to use existing  
> formats that don't have a convenient place to put such an ID. My  
> employer's INFO DTMF payload doesn't have a place to put it.   
> Another frequently used example is the exchange of JPG images for  
> whatever purpose. Again, no place to put an app level ID in the INFO  
> payload. You could put it in the INFO header put that would be a  
> layer violation, right?
>
> INFO to carry INFO package responses with no adverse affects to  
> layering so that's not it.
>
> Thanks,
> Anders
>
> Eric Burger wrote:
>> Let us try again.
>> That is like a "200 OK" in SIP.  The process monitoring port 5060,  
>> on the other hand, will hopefully come back with some sort of "4xx  
>> you suck" message, encapsulated over TCP, which TCP will  
>> acknowledge delivery of.
>> make SIP look like Bluetooth with its dozens of profiles for  
>> whether you are a data device, a speaker, a microphone, a headset  
>> (yes, which is different than a speaker and a microphone), and so on.
>> Let INFO be INFO: something that *transports* messages through a  
>> SIP Proxy network.  Note I say "through a SIP Proxy network."  If  
>> you do not want to traverse Proxies, use TCP :-)
>>>> delivery of this package, and I'm responding with 200 ok because  
>>>> it was delivered".  In other words treat INFO as a delivery  
>>>> vehicle, like MESSAGE, and as long as the package was delivered  
>>>> you send a 200 ok, with no correlation to if/when the package was  
>>>> opened and read successfully or not by a higher-layer info- 
>>>> package "consumer".
>>> level errors to be signalled with INFO error codes and/or allow  
>>> INFO responses to carry responses along the lines of what CSTA does.
>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 30 Nov 2008 18:58:45 -0500

But we can't _require_ a fully-layered model.  In other words, all packages have to gracefully handle failure responses to their INFO request which were caused by processing failure.  And if a package really cares about processing failure, then it could also define a way to indicate it in a subsequent separate INFO transaction.

INFO-DTMF is a good example of one that *won't care*.  There's no real point in indicating errors back.  That doesn't mean you can't send back a 4xx immediately in response to the INFO request - you can always do that - it just means we do NOT have to define a way to indicate error after that in an upstream INFO request.

And BTW, any package could define different content-type or body content or whatever for both the normal use and the error indication, so it won't need separate package names for each.  But anyway that's really up to the specific package to handle, not the main draft methinks.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Burger
> Sent: Sunday, November 30, 2008 5:28 PM
>

---

From: Anders Kristensen <[email-masked]>
Date: Sun, 30 Nov 2008 16:30:23 -0800

> example of how to do this right.

OK, it can be done using two packages. It seems a bit clumsy to me but 
it'll work.

> information flows, then you have two choices.  The first is that you are 
> using a dialog-related application-to-application messaging protocol 
> (INFO) because you want to send messages related to *this* dialog. Any 
> response belongs to the request. Fairly straight forward.  Otherwise, if 

I think we're talking past each other. The problem is not correlating to 
the dialog, it's correlating the app-level response to a particular 
app-level request within a given dialog.

> you have a package that is really using INFO for tunneling, then it is 
> most likely already doing some sort of multiplexing, which means you 
> already need some way of identifying what the messages are for and about.
> 

I don't think I buy that. If something can be accomplished with one INFO 
request people are going to wonder why they have to have two.

> 
> Of course, the problems listed below are sort of hyper-theoretical.  If 
> a UAC cannot get a message as simple as DTMF right, getting an error 
> message from the UAS saying the UAC got it wrong is not going to help.  
> I'll bet my next $100 dollars that a UAC that needs hints inside of a 
> package to get something as easy as DTMF right will core dump when it 
> gets an error.

Obviously, DTMF is not the problem. If you're only targeting 
applications as simple as DTMF then there's no problem. I think we have 
to expect it'll be used for all sorts of things, though, including 
request-response type apps.

Anders

>> indicate to the sender that a particular event could not be decoded. 
>> If I understand you correctly, the error indication would have to be 
>> Hence there's no distinction between the sender of DTMF events and the 
>> sender of responses to DTMF events. Unless the dtmf package is modeled 
>> as two separate INFO event packages.
>>
>> that don't have a convenient place to put such an ID. My employer's 
>> INFO DTMF payload doesn't have a place to put it.  Another frequently 
>> used example is the exchange of JPG images for whatever purpose. 
>> Again, no place to put an app level ID in the INFO payload. You could 
>> put it in the INFO header put that would be a layer violation, right?
>>
>>>> to do it. And why should they? I'm thinking we should allow 
>>>> app-level errors to be signalled with INFO error codes and/or allow

---

From: Anders Kristensen <[email-masked]>
Date: Sun, 30 Nov 2008 16:30:25 -0800

> INFO-DTMF is a good example of one that *won't care*.  There's no real point in indicating errors back.  That doesn't mean you can't send back a 4xx immediately in response to the INFO request - yo…

Either it's legal or it isn't. It's no good saying it's not legal but do 
what you gotta do. Are you saying the info-events draft should allow UAs 
to return INFO level errors in response to app-level problems?

> And BTW, any package could define different content-type or body content or whatever for both the normal use and the error indication, so it won't need separate package names for each.  But anyway…

So a UA would look at both Send-Info, Recv-Info and Accept in order to 
find out what are the info pkg capabilities of the peer? I guess that 
could work.

Anders

---

From: Eric Burger <[email-masked]>
Date: Sun, 30 Nov 2008 19:52:13 -0500

The gist is...

If one is building request-response type applications, first and  
foremost, why use INFO?  Using INFO says one needs the proxies in the  
path of the messaging.  Sounds like one really needs a rendezvous  
protocol, like SIP, and establish one's own path, e.g., like MSRP.

If one insists on using INFO, one clearly does not care about message  
size, bandwidth utilization, or network element burden. Since 80% of  
the uses of INFO will be for the simple stuff, and the other 20% will  
most likely be over yellow cables (e.g., a media server connected to  
an application server in the same rack), the "extra message" is a tiny  
price to pay to not screw oneself in the future.

> Eric Burger wrote:
[snip]
>> you have a package that is really using INFO for tunneling, then it  
>> is most likely already doing some sort of multiplexing, which means  
>> you already need some way of identifying what the messages are for  
>> and about.
>> PROBLEM 3: Another winner! If you care at all about performance,  
>> you would NEVER use INFO!!!!  Come on guys - let's look at DTMF:  
>> one to sixteen bytes of payload, two thousand bytes of SIP overhead.
>
> I don't think I buy that. If something can be accomplished with one  
> INFO request people are going to wonder why they have to have two.
>
>> Of course, the problems listed below are sort of hyper- 
>> theoretical.  If a UAC cannot get a message as simple as DTMF  
>> right, getting an error message from the UAS saying the UAC got it  
>> wrong is not going to help.  I'll bet my next $100 dollars that a  
>> UAC that needs hints inside of a package to get something as easy  
>> as DTMF right will core dump when it gets an error.
>
> applications as simple as DTMF then there's no problem. I think we  
> have to expect it'll be used for all sorts of things, though,  
> including request-response type apps.
[snip]

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 30 Nov 2008 21:16:16 -0500

> Sent: Sunday, November 30, 2008 7:30 PM
>
> Hadriel Kaplan wrote:
> > But we can't _require_ a fully-layered model.  In other words, all
> packages have to gracefully handle failure responses to their INFO request
> which were caused by processing failure.  And if a package really cares
> about processing failure, then it could also define a way to indicate it
> in a subsequent separate INFO transaction.
>

The info-events draft has no choice but to allow an INFO request to fail with a failure response code.  ISTM every SIP request type that can succeed can also fail with a failure response code.  I don't think we need a *new* response code.  One could use 415 or 400, or Paul suggested 488.  I would do whatever Subscribe/Notify/Message does in such cases.

And to be clear, I don't think ANY of this needs to be in the base draft.  If someone wants to define a package that has a body which can contain error information, and sends that in an INFO request after getting an INFO request it can't process, why should we say a package can't do that?  And I don't mean that in the sense of "let's be flexible" - I mean it's actually illogical to constrain what a package puts in its INFO message or why, at layer above SIP.  I don't even know how to word such language.  "You MUST NOT define a package which contains error information about your application"?

And I don't think we can reasonably mandate that the original INFO request only be responded to with 200 ok if the entire application processed it successfully.

For example, let's say INFO-DTMF actually cared about an error condition. (I don't think it does, but just for argument's sake)  You couldn't mandate it send that error in the response to the INFO, because there are cases where that would be impossible.  For example, a SIP-H.323 gateway would get the INFO and convert it to H.245-UII.  If we mandate sending back the error for the INFO, it would require waiting for the H.245 message to be successfully received on the H.323 side before sending back any response to the INFO, which can be quite long.  Not only would you get a bunch of retransmissions (if over UDP), but it may exceed the overall transaction timer itself.

I think that's why Subscribe had to send a Notify after subscription, as well.  The processing time for something at a layer above SIP is just not controllable at a SIP transaction layer.

But even given that - it can't stop a INFO-DTMF receiver from sending back a 4xx.

The real question is whether it would be allowed to send back application-layer information such as bodies in the response.  And I have no clue on that.  There's pro's/con's, as usual.

> find out what are the info pkg capabilities of the peer? I guess that

Actually I think we had consensus there would be no Send-Info defined in the draft.  But anyway no I don't think I meant that. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 30 Nov 2008 21:25:53 -0500

> Sent: Sunday, November 30, 2008 7:52 PM
>

Ummm... the UA may not care, but Proxies sure would.  And it's kinda the UA's decision of whether to use INFO or not, not the Proxies'.  If we can keep the message count down while still providing the INFO users with what they need, it would be better IMO.

-hadriel