Subject: Re: [Sip] INFO Framework - one pakage per INFO

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 1 Dec 2008 11:59:39 +0100

See below.

Keith 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: Saturday, November 29, 2008 4:50 AM
> To: Anders Kristensen
> Cc: SIP List
> Subject: Re: [Sip] INFO Framework - one pakage per INFO
> 
> 
> > -----Original Message-----
> > From: Anders Kristensen [mailto:[email-masked]]
> > Sent: Friday, November 28, 2008 9:44 PM
> >
> > 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.
> 
> 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".
> 
Correct. And why do something different when MESSAGE already does it
that way.

> 
> > 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.
> 
> Yeah, I think Eric's argument is for (2).  If they need it, 
> they pay for it.

Correct

A 3xx to 6xx indicates failure to deliver the info package to the
application above.

The simplest error recovery case which seems to apply in existing usage
is no information is sent in the reverse direction regarding application
error handling, or it is handled as part of the application protocol,
i.e. there is a message embedded in the package which in any case
generates a response within the application.
_______________________________________________
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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 1 Dec 2008 12:17:15 +0100

See below 

> Behalf Of Anders Kristensen
> Sent: Sunday, November 30, 2008 9:44 PM
> To: Eric Burger
> Cc: SIP List
> 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.
> 
The answer is, yes if that is what the application demands.

I would note that on the analogue network DTMF is unacknowledged. The
only way I know that my digits have been sucessfully received is when
call control advances a state. I don't know it has missed a digit until
the wrong person answers the call, or I get number unobtainable. I have
to go to MFC to get any form of acknowledged tone signalling, and as yet
I have not seen INFOs carrying R2 signalling packages.

So in this case, a SIP state change could well be an implicit
acknowledgement generated by the application, but that is not one
implied by any response to the INFO request.

> 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?
> 
Correct. And I see even more problems if you try and do it at the SIP
level.

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

Well as I said before, not all info packages require a direct response.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2008 09:53:21 -0500

Eric Burger wrote:
> Let us try again.
> 
> INFO is a method that *transports* Application-Level "messages".
> 
> INFO is NOT a method of Application-Level messaging.

I guess you are asserting the above, right?

Its possible that is what the original authors of INFO intended, though 
it isn't entirely clear to me if that is the case.

But the whole problem we have now is that INFO has evolved into 
something that may be different from what was originally intended. At 
this point we are trying to reverse engineer a better defined 
replacement to what INFO has become. If we don't accommodate the usage 
people need, then there will have been no point in doing it at all.

I honestly don't know at this point whether what you specify above is 
sufficient. At the very least, I think we need to *permit* the receiving 
application to signal a problem with the content of the package in the 
response to the info message. Perhaps we don't need to *require* that 
any problem with the content be signaled that way. However I do think it 
would be good to distinguish the case where the content is good from the 
case where the content hasn't yet been acted upon - probably using the 
200/202 response distinction that is used elsewhere.

And I do think we should at least specify how problems with the content 
may be reported in the info response - which error code(s) should be 
used. (For example, 415 has a very specific role here - if the C-T is 
incorrect for the package. But if the C-T is correct and:
(1) the content of the body part is inconsistent with the type
(2) the content of the body part is consistent with the type,
     but the content is semantically inappropriate
then the response to use is not clear. We could extend the definition of 
488 and/or 606 for this purpose, or we could pick something new. But we 
at least ought to make it clear what should be used for these cases.

Anders has argued for allowing content in the body of the INFO response 
to be significant. That is certainly a possibility, but I am not certain 
if the added complexity is justified. If so, then I think it should be 
the responsibility of the info package definition to specify which types 
go in requests, and which (if any) go in responses. But the info-package 
draft will still need to specify that this is legal, and how the body 
part carrying the response is indicated in the response message.

Beyond that, if there is a need for delayed responses I am fine with 
requiring that it be negotiated as distinct packages in each direction.

	Thanks,
	Paul

> 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:
> 
>>
>>
>> Hadriel Kaplan wrote:
>>>> 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.
>>> 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".
>>> 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: Anders Kristensen <[email-masked]>
Date: Mon, 01 Dec 2008 12:31:57 -0800

inline

> implied by any response to the INFO request.

The implementations of DTMF-over-INFO I'm familiar with will respond 
with 4xx error codes to malformed payload. My guess is that's extremely 
common.  This is arguably a layer violation but, I think, a fairly 
benign one.

Either we allow error responses in such cases or else we say just don't 
return an error (which I think rather limits the scope of this work) or 
else we say the error indication needs to be sent in an INFO in the 
opposite direction. OR we allow INFO responses to carry an app-level 
response in the payload.

> Correct. And I see even more problems if you try and do it at the SIP

Do you see any problems in carrying an app-level payload in 200 
responses to INFO?

> Well as I said before, not all info packages require a direct response.

No but those that do will IMHO not be served well by the info framework 
as it stands.

Anders

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Dec 2008 16:37:32 -0500

The problem with transporting application-level responses in the 200  
OK is what happens when the 200 OK gets dropped on the floor?

On Dec 1, 2008, at 3:31 PM, Anders Kristensen wrote:

>>> From: [email-masked] [mailto:[email-masked]] On Behalf  
>>> Of Anders Kristensen
>>> 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.
>>>
> with 4xx error codes to malformed payload. My guess is that's  
> extremely common.  This is arguably a layer violation but, I think,  
> a fairly benign one.
>
> Either we allow error responses in such cases or else we say just  
> don't return an error (which I think rather limits the scope of this  
> work) or else we say the error indication needs to be sent in an  
> INFO in the opposite direction. OR we allow INFO responses to carry  
> an app-level response in the payload.
>
>>> 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.
> No but those that do will IMHO not be served well by the info  
> framework as it stands.
>
> Anders

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 01 Dec 2008 14:10:52 -0800

I don't follow. The 200 is sent reliably. Why would it get dropped and 
by whom?

Eric Burger wrote:
> The problem with transporting application-level responses in the 200 OK 
> is what happens when the 200 OK gets dropped on the floor?
> 
>>>> 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.
>>>>
>>>> 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.
>>>>
>> extremely common.  This is arguably a layer violation but, I think, a 
>> fairly benign one.
>>
>> work) or else we say the error indication needs to be sent in an INFO 
>> in the opposite direction. OR we allow INFO responses to carry an 
>> app-level response in the payload.
>>
>>>> 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 
>>>> 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.

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Dec 2008 17:21:20 -0500

What you are asking for is the UAS to keep state indefinitely on each  
200 OK, because the UAC may or may not be there to retransmit the  
first INFO request.  That does not sound like an ideal design.

On Dec 1, 2008, at 5:10 PM, Anders Kristensen wrote:

> I don't follow. The 200 is sent reliably. Why would it get dropped  
> and by whom?
>
> Eric Burger wrote:
>> The problem with transporting application-level responses in the  
>> 200 OK is what happens when the 200 OK gets dropped on the floor?
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> events and the sender of responses to DTMF events. Unless the  
>>>>> dtmf package is modeled as two separate INFO event packages.
>>>>>
>>> The implementations of DTMF-over-INFO I'm familiar with will  
>>> respond with 4xx error codes to malformed payload. My guess is  
>>> that's extremely common.  This is arguably a layer violation but,  
>>> I think, a fairly benign one.
>>>
>>> don't return an error (which I think rather limits the scope of  
>>> this work) or else we say the error indication needs to be sent in  
>>> an INFO in the opposite direction. OR we allow INFO responses to  
>>> carry an app-level response in the payload.
>>>
>>>>> 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?
>>>>>
>>>>> 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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 17:41:07 -0500

Umm, wouldn't it only keep it for the duration of a transaction lifetime, which is the same as it would have to do if it were to send it in an upstream INFO request?

PUBLISH, for example, does this doesn't it?  You don't respond to a PUBLISH until you've fully processed the publish request, including all Event Package body content. (and both request and response can have bodies for their event package)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Burger
> Sent: Monday, December 01, 2008 5:21 PM
> To: Anders Kristensen
> Cc: SIP List

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 01 Dec 2008 14:48:01 -0800

Yes, the UAS only needs to keep transaction state for some bounded 
period of time as defined by the RFC 3261 non-INVITE server transaction FSM.

Maybe Eric has in mind a UAS that responds to INFOs statelessly as per 
3261 sec 8.2.7. I really don't think we need to worry about making that 
kind of optimization impossible.

Anders

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Dec 2008 18:07:37 -0600

Anders Kristensen wrote:

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

don't we have a SIP error code for "body not understood"?

I'd really like to NOT design every possible application's state into
SIP. Otherwise, we'll end up with error codes for "no, I want a blue one!"

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Dec 2008 18:11:40 -0600

Anders Kristensen wrote:

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

Use a transaction-correlation ID in your application-level protocol
(i.e, in the package specification) if you need this sort of function.
It's not SIP's problem.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2008 19:26:15 -0500

> don't we have a SIP error code for "body not understood"?

Unfortunately we don't quite have that, though we have something close:

488 / 606 apply to the body, and have the names Not Acceptable Here / 
Not Acceptable which sound about right. But the description says:
    some aspects of the session description such as the requested media,
    bandwidth, or addressing style were not acceptable.
which really only applies to SDP (-: or SDPng :-).

415 works when the Content-Type itself is not supported, but not for the 
other cases.

I'm inclined to stretch the definition of 488/606 to cover arbitrary 
bodies. Or we could define a new code that has the more generic meaning.

> SIP. Otherwise, we'll end up with error codes for "no, I want a blue one!"

That is the problem with 488 as it stands.

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Dec 2008 18:38:13 -0600

Paul Kyzivat wrote:
> it isn't entirely clear to me if that is the case.\

I believe that's what we meant :-)

If a UAS doesn't understand the body of an INFO, it presumably sends a
415 (like it would for any other required body part it doesn't understand).

I quote from RFC 2976:

      If the INFO request contains a body that the server does not
      understand then, in the absence of INFO associated processing
      rules for the body, the server MUST respond with a 415 Unsupported
      Media Type message.

This is significant for choosing which of several alternative body types
might be supported for a given package.

If the "not understood" is at the level of the application state, fixing
that is an application problem, not a problem for the SIP protocol. Fix
it in the package, not the transport.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 01 Dec 2008 16:48:39 -0800

> (i.e, in the package specification) if you need this sort of function.

I don't think I'm trying to make it "SIP's problem".

I'm arguing that if a response is needed it's much simpler and just all 
around better to do the response-to-request correlation by sending the 
app-level response in the 200 response to INFO as opposed to sending it 
in a separate INFO going in the opposite direction. It doesn't violate 
layering and I haven't heard of any real problem with it.

Anders

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Dec 2008 18:51:46 -0600

> layering and I haven't heard of any real problem with it.

It means that the stack can't send a 200 response to INFO until it has
been directed to by the application. That seems like a layering problem
to me, not to mention a major stack rewrite.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 01 Dec 2008 19:32:37 -0800

> to me, not to mention a major stack rewrite.

Right, I'm sure that's a total stack rewrite. It's a wonder how people 
manage to send DTMF in INFO today. With app-generated error codes.

Anders

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 22:54:55 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Monday, December 01, 2008 7:52 PM
>

Ya know, I would have thought so too.  But then I checked out PUBLISH.  It does exactly that: no response until you've fully processed the event package.  Strange.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 23:28:19 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Anders Kristensen
> Sent: Monday, December 01, 2008 10:33 PM
>
> Dean Willis wrote:
> >

I don't think he means it would be a stack re-write for you (or most people using info-dtmf or that matter).  He just means that as it stands right now per the INFO RFC, one could build a SIP Stack that uses INFO in a completely layered approach.  It would interoperate with an integrated stack for info-dtmf, because DTMF as an application doesn't really care about failed remote processing, so neither side would care and they'd both interoperate.  And for info-dtmf there is no application data returned on error, afaik.

Why don't we just compromise and do what other similar methods do: let the base draft say the package decides its own needs, but that it is RECOMMENDED to handle application-level errors in a separate transaction?  This still provides interoperability, because we negotiate supported packages to begin with and if you don't want to support a direct response you don't have to support that package; and if we find packages that really need/benefit from a direct response, they can argue their case.

BTW, when we talk about application-layer error, I hope we're not talking about content errors like XML formatting errors.  Because a Firewall could process that and decide to reject malformed XML, and the Firewall will have no application-layer for the package.
Even in a "layered" approach, delivery failure due to a 400 response is still sent up to the application caller I assume?

-hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 2 Dec 2008 14:19:08 +0100

Inline 

Keith

> Sent: Monday, December 01, 2008 8:32 PM
> To: DRAGE, Keith (Keith)
> Cc: Eric Burger; SIP List
> >> problematic or at least warrants some discussion in terms 
> of where it 
> >> leads. My worry is that it makes it significantly more tedious to 
> 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 
> > call control advances a state. I don't know it has missed a digit 
> > until the wrong person answers the call, or I get number 
> unobtainable. 
> > I have to go to MFC to get any form of acknowledged tone 
> signalling, 
> > and as yet I have not seen INFOs carrying R2 signalling packages.
> > 
> respond with 4xx error codes to malformed payload. My guess 
> is that's extremely common.  This is arguably a layer 
> violation but, I think, a fairly benign one.

Depends what you mean by a malformed payload. If it is the syntax of the body itself, I would argue that it is reusing a lower layer mechanism because it just happens to do the right thing, rather than something that is correct from a layering point of view.

> 
> Either we allow error responses in such cases or else we say 
> just don't return an error (which I think rather limits the 
> scope of this work) or else we say the error indication needs 
> to be sent in an INFO in the opposite direction. OR we allow 
> INFO responses to carry an app-level response in the payload.
> 

INFO must carry a response. 

> > 
> >> 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?
> >>
> Do you see any problems in carrying an app-level payload in 
> 200 responses to INFO?
> 
Yes. Because distinguishing real application responses from application functions that themselves require a response is almost impossible. So you end up putting payload in a 200 (OK) response to info for which you now need to generate an application level response. What next? Well you need to use an INFO to reject it. Which leads one directly to say that application level responses should go in an INFO in the first place.

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 2 Dec 2008 14:39:55 +0100

I don't remember any history of this, but would contend that the way RFC
3903 text is written in regards to bodies in responses is tantamount to
saying "bodies in responses is for further study". It is basically
trying to say, if in implementing this you receive a body in a response,
then don't start failing things at the SIP transaction level.

And remember, this requires an event package to define the usage, and
you need RFCs to define event packages, so I suspect any expert review
or above would take a very deep look at any such definition.

Keith 

> Sent: Monday, December 01, 2008 10:41 PM
> To: Eric Burger; Anders Kristensen
> Cc: SIP List
> Umm, wouldn't it only keep it for the duration of a 
> transaction lifetime, which is the same as it would have to 
> do if it were to send it in an upstream INFO request?
> 
> PUBLISH, for example, does this doesn't it?  You don't 
> respond to a PUBLISH until you've fully processed the publish 
> request, including all Event Package body content. (and both 
> request and response can have bodies for their event package)
> 
> -hadriel
> 
> 
> Behalf Of 
> > Eric Burger
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Dec 2008 13:14:49 -0500

Right, so that's one possible direction to go for INFO as well: don't mandate any model in the base spec.  Keep it simple.  Let the packages do their own dirty work, under review.
-hadriel

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2008 8:40 AM
> To: Hadriel Kaplan; Eric Burger; Anders Kristensen
> Cc: SIP List
> Subject: RE: [Sip] INFO Framework - one pakage per INFO
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2008 13:35:49 -0500

> Right, so that's one possible direction to go for INFO as well: don't mandate any model in the base spec.  Keep it simple.  Let the packages do their own dirty work, under review.

I'm fine with that, as long as we leave some basic hooks for the 
packages to use. In particular:

- *some* error code that can be returned as the response to INFO,
   which indicates: I didn't like the *content* of the package.
   If we have a single response that can be used for that, then
   I expect that Reason can be used to refine it.

- don't define the meaning of a body in the response, but
   don't forbid it either. Let the significance be defined by
   the package.

- perhaps draw the distinction between 200 and 202 responses,
   where 200 means the package has been "accepted" by the receiving
   application and 202 means the package has simply been "queued"
   for the receiving app. (I don't know if this distinction is
   useful here or not.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Dec 2008 13:47:18 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2008 1:36 PM
>

Is there some reason you need a different response code than 415 or 400?  Do you think the UAC can take some different automated action due to getting back a 488-type response than a 400, for example?

[I personally hate new response codes - middleboxes always seems to be asked to map them to a different number.]

>    I expect that Reason can be used to refine it.

Unless this has changed, I thought the Reason header was only allowed in requests? (even though I know people put it in responses, and honestly it was silly to only apply it to requests to begin with)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2008 15:27:37 -0500

> Is there some reason you need a different response code than 415 or 400?  Do you think the UAC can take some different automated action due to getting back a 488-type response than a 400, for examp…

I hate using the -00 responses because they are so vague. If worse comes 
to worse then 400 can be used with a phrase to describe the actual 
problem. That can be enough for debugging. (I don't really expect 
anybody is going to recover from these errors.) But if somebody responds 
to me with this sort of error I would like to be able to tell that is 
the problem without having to talk to a developer of the responding device.

The main thing is to give guidance on what error should be used.

> Unless this has changed, I thought the Reason header was only allowed in requests? (even though I know people put it in responses, and honestly it was silly to only apply it to requests to begin wi…

    The Reason header field MAY appear in any request within a dialog, in
    any CANCEL request and in any response whose status code explicitly
    allows the presence of this header field.

AFAIK there are no responses that allow it. But we could make a 
normative change to do so, to whatever response code we decide should be 
used. Or we can just punt this to the reason-phrase of the response.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 02 Dec 2008 15:02:22 -0600

Hadriel Kaplan wrote:

> 
> Why don't we just compromise and do what other similar methods do:
> let the base draft say the package decides its own needs, but that it
> is RECOMMENDED to handle application-level errors in a separate
> transaction?  This still provides interoperability, because we
> negotiate supported packages to begin with and if you don't want to
> support a direct response you don't have to support that package; and
> if we find packages that really need/benefit from a direct response,
> they can argue their case.

Hadriel arguing in favor of optionality and requirements language at
less than MUST strength? Never! Who are you , and why are you posting
from Hadriel's address?

> BTW, when we talk about application-layer error, I hope we're not
> talking about content errors like XML formatting errors.  Because a
> Firewall could process that and decide to reject malformed XML, and
> the Firewall will have no application-layer for the package. Even in
> a "layered" approach, delivery failure due to a 400 response is still
> sent up to the application caller I assume?

I'm certainly afraid that people have things like XML-formatting errors
and  "I parsed  the data you sent, but it did not make sense in my
application's current context" in mind.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 02 Dec 2008 15:12:25 -0600

> INFO must carry a response. 

Putting application-level data into an INFO response is problematic as
this may make the INFO body larger than the transport package size, and
we have no way to reject large responses.

This is exactly why we stalemated on diagnostic responses.

Given the characteristics of SIP-as-transport, the only reasonable thing
to do (beside change SIP) is to require all application-layer responses
use SIP requests in the return direction onstead of piggybacking on the
SIP response. The SIP response can, in general, tells us only about the
handling of the request's delivery at a SIP level, not an application level.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2008 16:27:12 -0500

> handling of the request's delivery at a SIP level, not an application level.

Then I guess we had better stop passing SDP in responses.

Why is it that responses can have a body???

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Dec 2008 16:48:38 -0500

> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2008 4:02 PM
>
> Hadriel Kaplan wrote:
>

I think Kenny Rogers (or Don Schlitz) said it best: You got to know when to hold 'em, know when to fold 'em. :)

If we can't agree on the right model for all INFO usages, then it's better to punt.  I don't think it will cause interop issues, because this is just a base spec and the details will be in the packages.

-hadriel

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 02 Dec 2008 14:19:34 -0800

That all sounds good to me.

Thanks,
Anders

Paul Kyzivat wrote:
> 
> 
> Hadriel Kaplan wrote:
>> Right, so that's one possible direction to go for INFO as well: don't 
>> mandate any model in the base spec.  Keep it simple.  Let the packages 
>> do their own dirty work, under review.
>> -hadriel
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 2 Dec 2008 23:25:44 -0600

> Why is it that responses can have a body???

We got lucky with SDP, in that early versions of SDP combined with the  
cruft in early versions of SIP actually fit into one UDP packet. One  
of the probable issues with SDP-NG is that it might well not enjoy  
that characteristic, and as we add countless options, secondary  
bodies, and other cruft to SIP we're in danger of crossing the line.   
Will  UDP work for INFO responses? I dunno. Maybe, if we're lucky.

Do you feel lucky?

SIP's UDP request-response paradigm was at best excessively narrow in  
applicability and at worst ill-conceived. We'd have a lot fewer  
headaches if we had "offer" requests and "answer" requests at the  
application layer, and a clear demarc between that application layer  
and SIP's message-transport/rendezvous functions. Or if we'd just used  
TCP for everything to start with.

Of course, one might subscribe to the philosophy that since we've so  
hopelessly muddled the application and the transport in existing SIP  
that we might as well do so for revised-INFO so that we're at least  
consist in our mistakes. I find that to be a sensible but depressing  
argument.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Dec 2008 08:53:09 +0000

> Behalf Of Christer Holmberg
> Sent: 28 November 2008 19:38
> To: Hadriel Kaplan; Eric Burger
> Cc: SIP List
> Hi, 
> >>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.
> >
> >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 :)
[JRE] The answer is we didn't have a requirement for this. I agree with
Hadriel's a), b) and c).

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Dec 2008 09:11:38 +0000

Also I don't think methods such as SUBSCRIBE, NOTIFY and PUBLISH allow
>1 event package, so why should INFO allow >1 Info package?

John

> From: Elwell, John 
> Sent: 03 December 2008 08:53
> To: 'Christer Holmberg'; Hadriel Kaplan; Eric Burger
> Cc: SIP List
> [JRE] The answer is we didn't have a requirement for this. I 
> agree with Hadriel's a), b) and c).
> 
> John
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 4 Dec 2008 13:15:33 +0100

We do allow multipart for legacy INFO (well, at least we don't disallow
it).

Do we need to say anything about the number of packages?

Regards,

Christer 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: 3. joulukuuta 2008 11:12
> To: Christer Holmberg; Hadriel Kaplan; Eric Burger
> Cc: SIP List
> > > Of Christer Holmberg
> > > body-handling spec?
> > [JRE] The answer is we didn't have a requirement for this. I agree 
> > with Hadriel's a), b) and c).
> > 
> > John
> > 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Dec 2008 10:47:11 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, December 04, 2008 7:16 AM
>

I'm not sure I understand the question.  We should say: 1 INFO, 1 package.  You make it sound like a package is a body-part.  It's not.  A package just defines a specific message use context, and rules thereof.  You can define a info-package that specifies no bodies, for example.

Adding support for multiple packages, is like asking for a message to have multiple usage contexts and rules.  It makes my head hurt. :)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Dec 2008 10:09:50 -0600

On Dec 4, 2008, at 9:47 AM, Hadriel Kaplan wrote:

> I'm not sure I understand the question.  We should say: 1 INFO, 1  
> package.  You make it sound like a package is a body-part.  It's  
> not.  A package just defines a specific message use context, and  
> rules thereof.  You can define a info-package that specifies no  
> bodies, for example.
>
> Adding support for multiple packages, is like asking for a message  
> to have multiple usage contexts and rules.  It makes my head hurt. :)
>

I concur strongly with this position.

I started thinking about the which-application-do-I-give-this-message- 
to API, and realized that for some API models, multiple packages per  
INFO would be a major furball. Let's just not go there.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2008 11:38:47 -0500

I'm ok with this, and I thought it had already been settled. Why are we 
rehashing it?

	Paul

Dean Willis wrote:
>> package.  You make it sound like a package is a body-part.  It's not.  
>> A package just defines a specific message use context, and rules 
>> thereof.  You can define a info-package that specifies no bodies, for 
>> example.
>>
>> Adding support for multiple packages, is like asking for a message to 
>> have multiple usage contexts and rules.  It makes my head hurt. :)
>>
> 
> I started thinking about the which-application-do-I-give-this-message-to 
> API, and realized that for some API models, multiple packages per INFO 
> would be a major furball. Let's just not go there.
> 
> -- 
> Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Dec 2008 12:14:16 -0600

Christer asked "Do we need to say anything about the number of  
packages?"

to which I believe we have an answer: "Yes. One per INFO".

--
Dean

On Dec 4, 2008, at 10:38 AM, Paul Kyzivat wrote:

> I'm ok with this, and I thought it had already been settled. Why are  
> we rehashing it?
>
> 	Paul
>
> Dean Willis wrote:
>> I started thinking about the which-application-do-I-give-this- 
>> message-to API, and realized that for some API models, multiple  
>> packages per INFO would be a major furball. Let's just not go there.
>> -- 
>> Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 4 Dec 2008 20:35:03 +0100

Hi, 

packages?"
>to which I believe we have an answer: "Yes. One per INFO".

IF we would end up using CID, I still don't see the problem. There would
be a direct "link" between a Info-Package value and a body part
(assuming there is an associated body part).

If we are NOT going to use CID (or any other mechanism which creates the
same link) I am ok with one-per-INFO.

Regards,

Christer

On Dec 4, 2008, at 10:38 AM, Paul Kyzivat wrote:

>>>> We do allow multipart for legacy INFO (well, at least we don't 
>>>> disallow it).
>>>>
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments on the application of sip
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

_______________________________________________
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
_______________________________________________
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: Dean Willis <[email-masked]>
Date: Thu, 4 Dec 2008 17:23:36 -0600

> same link) I am ok with one-per-INFO.

And that's why we're still discussing it.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Dec 2008 19:43:38 -0500

> Sent: Thursday, December 04, 2008 6:24 PM
>

No, we're still discussing it because you people are stubborn, as am I. ;)
We clearly all have different definitions for the KISS principle, which is probably natural.

Let's imagine, for sake of argument, that the solution to the general SIP message problem of dis-ambiguating body parts which don't belong to the message context, were to be solved by creating a CID for all the body-parts that *did* belong to the message context.  I think that would be incredibly foolish, maybe even pathological, but let's just pretend that we decided it was the right solution... (nice setup, eh? :)
Would we:
a) Put the CID URL in specific SIP headers unique to each message type, for example "Info-Package:", "Event:", "Invite-cid:", "Message-cid:", etc.?
b) Put the CID URL in a SIP message header common to all message types?

Now I would claim that any sane human would go with option (b), thereby nixing multiple Info-Packages to begin with. (and oh by the way showing why we shouldn't try to solve this for Info only)
But let's just suppose that we chose option (a), to confirm our pathological behavior...

Then someday in the future we define Info-Packages "Foo" and "Bar".  I send them both in an INFO.  I get a 400 back.  Which one failed?  One of them could be a critical type, with app-level failure maybe even sent in upstream requests - but I got a 400 and no upstream request - it's possible the critical one didn't even get to the app layer, or it's the other package context that failed.  Hmm.

Or let's say we define an Info-Package "Foo", and for some reason we decide it's really important and needs a special SIP header for it too in the INFO request.  Like, oh, I don't know... a header called "User-to-User" to carry UUI data.  (I know, I have an active imagination!)  Which package would this header belong to?  I mean, my god there could be another future package which needs that same header too!  Would we create a "Header-ID" param and HID URL too??

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Dec 2008 01:57:13 +0100

I don't want to go this way at all.

I guess I could live with a 4xx - 6xx response being an implicit indication of failure of a INFO request, even it is caused by the application, rather than analysis at the SIP level.

As soon as you want detail of the failure, that has to be an application level information, and it has to be transferred as an INFO package body, and in my view that still has to go in another INFO request, and not in the response.

And for the Reason header proposal/suggestion below, any standards track RFC can define the usage of Reason in response, but to my mind this changes the semantics of the Reason header way beyond its original intention.

regards

Keith

> Behalf Of Paul Kyzivat
> Sent: Tuesday, December 02, 2008 8:28 PM
> To: Hadriel Kaplan
> Cc: SIP List
> > Is there some reason you need a different response code 
> than 415 or 400?  Do you think the UAC can take some 
> different automated action due to getting back a 488-type 
> response than a 400, for example?
> 
> I hate using the -00 responses because they are so vague. If 
> worse comes to worse then 400 can be used with a phrase to 
> describe the actual problem. That can be enough for 
> debugging. (I don't really expect anybody is going to recover 
> from these errors.) But if somebody responds to me with this 
> sort of error I would like to be able to tell that is the 
> problem without having to talk to a developer of the 
> responding device.
> 
> > [I personally hate new response codes - middleboxes always 
> seems to be 
> > asked to map them to a different number.]
> > 
> > 
> > Unless this has changed, I thought the Reason header was 
> only allowed 
> > in requests? (even though I know people put it in responses, and 
> > honestly it was silly to only apply it to requests to begin with)
> 
> AFAIK there are no responses that allow it. But we could make 
> a normative change to do so, to whatever response code we 
> decide should be used. Or we can just punt this to the 
> reason-phrase of the response.
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Dec 2008 00:35:14 -0500

Keith,

OK, I am willing to give up on the Reason phrase.
We already have precedent (488) for a 4xx response indicating trouble 
with the content of a body. At the moment it seems to be specific to SDP.

The question is:
- can we use 488/606 to mean trouble with some other kind of body?
- or must we reserve 488/606 for SDP. If it is only for SDP:
   - can we have a different code to mean "other body trouble"?
   - or must we settle for 400 for this?

I'm willing to live with 400 if that is what others prefer.
I am ambivalent about generalizing 488.
Another code would be nice, but I think we will spin awhile getting 
agreement on it.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 05 Dec 2008 07:24:44 +0000

I think the 488 precedent was unfortunate. If you send SDP offer in a
reliable provisional response or a 2xx response, 488 isn't available to
you (except I suppose you could put a Reason header in the PRACK or ACK
request, but I don't really want to go there).

So I don't think we need we need a way of indicating in an INFO response
problems with body content in the request.  Let the application send an
INFO request in the reverse direction.

John

> Sent: 05 December 2008 05:35
> To: DRAGE, Keith (Keith)
> Cc: SIP List
> > I guess I could live with a 4xx - 6xx response being an 
> implicit indication of failure of a INFO request, even it is 
> caused by the application, rather than analysis at the SIP level.
> > 
> > As soon as you want detail of the failure, that has to be 
> an application level information, and it has to be 
> transferred as an INFO package body, and in my view that 
> still has to go in another INFO request, and not in the response.
> > 
> > And for the Reason header proposal/suggestion below, any 
> standards track RFC can define the usage of Reason in 
> response, but to my mind this changes the semantics of the 
> Reason header way beyond its original intention.
> > 
> > regards
> > 
> > Keith
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 5 Dec 2008 14:10:25 +0100

Hi,

>>IF we would end up using CID, I still don't see the problem. There  
>>would be a direct "link" between a Info-Package value and a body part
>>If we are NOT going to use CID (or any other mechanism which creates  
>>the same link) I am ok with one-per-INFO.
>

That is not true. The do-we-need-a-linkage question also apply to multipart in genral, e.g. where you do have only one info package body part, in addition to some other body parts.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 10:30:32 -0500

> Elwell, John

The same could be said of 413, 415, 493, etc.  If the UAC can't fundamentally handle an INVITE response's body, it can send a CANCEL, with the Reason header.  I thought that was the point of the Reason header - to be able to send the failure reason in requests.
>From RFC 3326:
   "SIP responses already offer a means of informing the user of why a
   request failed.  The simple mechanism in this document accomplishes
   something roughly similar for requests."

> INFO request in the reverse direction.

That's not always technically possible, AFAICT.  If the body content is bad, there's no guarantee it even got to the app-layer.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Dec 2008 10:32:02 -0600

> request, but I don't really want to go there).

Which is why the SDP response should have been in a request sent back  
from terminating UA to originating UA, and not in an answer. But that  
cat and most of its relatives are out of the bag, at least for SIP  
2.0. Note for posterity: you can't fix a broken leg with a band-aid  
well enough for running on, but if you add enough band-aids, you just  
might make a squishy-sticky prosthetic that lets you limp along.

> INFO request in the reverse direction.

I concur. It might be reasonable for the SIP stack to send a 4xx  
response meaning "I have no idea what to do with this INFO body; I  
either don't understand it, or I have no application to hand it to".  
Beyond that, it just isn't SIP's job to express application semantics  
in a response code.

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 6 Dec 2008 15:01:13 +0100

Hi, 

>>would be a direct "link" between a Info-Package value and a body 
>>part (assuming there is an associated body part).
>>
>No, we're still discussing it because you people are stubborn, as am I.
;) We clearly all have different definitions for the KISS principle,
which is probably natural.

We also seem to have different definitions for the scope of what we are
supposed to do as part of this WG item, which is also natural - at least
in SIP :)

>Let's imagine, for sake of argument, that the solution to the general
SIP message problem of dis-ambiguating body parts which don't belong to
the message context, were to be solved by creating a CID for 
>all the body-parts that *did* belong to the message context.  I think
that would be incredibly foolish, maybe even pathological, but let's
just pretend that we decided it was the right solution... (nice 
>setup, eh? :) Would we:
>a) Put the CID URL in specific SIP headers unique to each message type,
for example "Info-Package:", "Event:", "Invite-cid:", "Message-cid:",
etc.?
>Now I would claim that any sane human would go with option (b), thereby
nixing multiple Info-Packages to begin with. (and oh by the way showing
why we shouldn't try to solve this for Info only) But let's 
>just suppose that we chose option (a), to confirm our pathological
behavior...
>
>Then someday in the future we define Info-Packages "Foo" and "Bar".  I
send them both in an INFO.  I get a 400 back.  Which one failed?  One of
them could be a critical type, with app-level failure maybe 
>even sent in upstream requests - but I got a 400 and no upstream
request - it's possible the critical one didn't even get to the app
layer, or it's the other package context that failed.  Hmm.

We already have that problem today. A specific SIP request can "fail"
due to many reasons (not only related to message bodies), but we are
only allowed to send one single response code back.

>Or let's say we define an Info-Package "Foo", and for some reason we
decide it's really important and needs a special SIP header for it too
in the INFO request.  Like, oh, I don't know... a header called 
>"User-to-User" to carry UUI data.  (I know, I have an active
imagination!)  Which package would this header belong to?  I mean, my
god there could be another future package which needs that same header 
>too!  Would we create a "Header-ID" param and HID URL too??

Is this really a problem for non-INFO message bodies? There is no CID
for SDP, but clients seem to be able to deal with it anyway. 

Because, in most cases today clients are able to find out what is in a
message body, and what to do with it, based on the Content-Type value.

There are multiple usages of XML message bodies, but even in all of
those cases I think the Content-Type value gives more information than
simply saying "XML".

So, something like "Content-Type: application/info+foo" would solve
this. No need for new headers, no need for CIDs, no need for nothing...
That is MY definition of KISS (apart from being one of the coolest rock
band :)

I hear Paul's argument that people may want to used the same C-T value
as they use for legacy INFO today, but I really see no problem in using
something else. They can still use exactly the same data content.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Dec 2008 12:34:09 -0500

Hi Christer,
I think there is general consensus that this problem is not unique to INFO, and is in fact applicable to all message types, so we should be discussing this in the other thread for that purpose.  I will respond to your comments in that one, just to be consistent.

-hadriel

> Sent: Saturday, December 06, 2008 9:01 AM
> To: Hadriel Kaplan; Dean Willis
> Cc: SIP List; Paul Kyzivat

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Dec 2008 13:09:33 -0500

> for SDP, but clients seem to be able to deal with it anyway.

There is no CID, but there is a C-D: an implicit C-D of "session" for app/sdp, and "render" for everything else.  And I am not at all advocating that we use CID for the body-parts that actually belong to the message context.  Quite the contrary, I think it would be silly to do that.

And yes it is a potential problem for non-INFO message bodies, in exactly the same way it's a potential problem for INFO.  There is nothing unique about INFO which makes the problem only applicable to it.

To reiterate the "problem": the issue is not that messages can have multiple body-parts.  The issue is that one or more body-parts may not actually be intended for the message's context.  In other words, they're not intended for the application-layer processing logic specific to that method (and package if there is one).  For example, when I send a SUBSCRIBE request, the method name "SUBSCRIBE" and the Event header package name identify a specific context -  a specific use-case of the message with its own set of rules and for a specific application-layer above, which actually understands that package's specific semantics and how to process the higher-level "subscription".

So if the SIP message has body-parts, and one of them is actually not intended for that package but is instead just a generic add-on, like geoloc for example, we need to dis-ambiguate that add-on body-part(s) from the others.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Dec 2008 15:49:52 -0500

> That is MY definition of KISS (apart from being one of the coolest rock

For one thing, we don't need to change ANY C-* in the INFO message and still get what we want - if that's not "simple" then I don't know what is.  :)

It is also debatable that having a solution for a specific message type and then a different solution for other message types is "simple"; or even having a body "type" that is unique for each message type vs. generic to all is "simple".  It may be simpler for the first message type you do it to, but then you have to reproduce that code for all message types anyway.

> message body, and what to do with it, based on the Content-Type value.

No, that may be what some of them do in code, or what it appears like they're doing from a wireshark trace, but what 3261 says is that in fact there is a C-D that extends the C-T.  It just happens to be that "session" is the implicit C-D for "application/sdp", and "render" is the implicit C-D for everything else.  So as far as we know they're actually doing it right.

BTW, it's not that I disagree with you that content-types to date have been unambiguous in reality.  They have, afaik.  And I think we would be well-advised to keep future extensions from re-using already defined C-T's if ambiguity could occur.  For most things we're pretty safe.  For example, any future Info package would be safe to re-use existing C-T's, because a negotiation mechanism is in place to indicate package support, so you wouldn't get a message with the package to begin with if you didn't understand it and support disambiguating body parts.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 6 Dec 2008 22:09:14 +0100

Hi, 

>
>There is no CID, but there is a C-D: an implicit C-D of "session" for
app/sdp, and "render" for everything else. 

Sure. But, assume we would also be using SDPng. It would also have a C-D
value of "session", but I assume the C-T value would be different than
"app/sdp". You need to know what is in the body, so you can process and
parse it correctly.

>And I am not at all advocating that we use CID for the body-parts that
actually belong to 
>the message context.  Quite the contrary, I think it would be silly to
do that.
>
>And yes it is a potential problem for non-INFO message bodies, in
exactly the same way it's a potential problem for INFO.  There is
nothing unique about INFO which makes the problem only applicable to 
>it.
>
>To reiterate the "problem": the issue is not that messages can have
multiple body-parts.  The issue is that one or more body-parts may not
actually be intended for the message's context.  In other words, 
>they're not intended for the application-layer processing logic
specific to that method (and package if there is one).  For example,
when I send a SUBSCRIBE request, the method name "SUBSCRIBE" and the 
>Event header package name identify a specific context -  a specific
use-case of the message with its own set of rules and for a specific
application-layer above, which actually understands that package's 
>specific semantics and how to process the higher-level "subscription".
>
>So if the SIP message has body-parts, and one of them is actually not
intended for that package but is instead just a generic add-on, like
geoloc for example, we need to dis-ambiguate that add-on body-
>part(s) from the others.

It should be defined in what SIP messages geoloc information may be
transported, and what the receiver supporting it is supposed to do with
it. As we do for SDP. SDP in CANCEL has no meaning, for example, so it
is seen as a protocol error to send SDP in CANCEL.

I see no reason why we should solve things so that one can insert
whatever, wherever...

And, as far as INFO is concerned, I guess we all agree that info
packages are within the context of INFOs. BUT, you still need to know
body part(s) contain info package bodies, and what info package is
containded in a specific body part. C-T can do that, as it does for XML.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 6 Dec 2008 22:37:04 +0100

Hi, 

>>That is MY definition of KISS (apart from being one of the coolest 
>>rock band :)
>
>For one thing, we don't need to change ANY C-* in the INFO message and
still get what we want - if that's not "simple" then I don't know what
is.  :)
>
>It is also debatable that having a solution for a specific message type
and then a different solution for other message types is "simple"; or
even having a body "type" that is unique for each message 
>type vs. generic to all is "simple".  It may be simpler for the first
message type you do it to, but then you have to reproduce that code for
all message types anyway.

If we have a package specific C-T value we probably don't even need the
Info-Package header. So, absolutely no reason to link a header with a
body part, because there is no header. Just like SDP.

We use Send-Info to negotiate that we support foo, and then I send you
foo with C-T: application/info+foo. Very simple.

If people then want to define some generic SIP mechanism for some
problem I am not sure we all agree what it is, fine. If needed, you can
then use that solution also for your info package body parts.

>
>No, that may be what some of them do in code, or what it appears like
they're doing from a wireshark trace, but what 3261 says is that in fact
there is a C-D that extends the C-T.  It just happens to be 
>that "session" is the implicit C-D for "application/sdp", and "render"
is the implicit C-D for everything else.  So as far as we know they're
actually doing it right.

In my experience, the problem is not "context", because it is know what
information is sent in what message. In addition, C-T (together with C-D
if you like) tells you what a body part contains, so you can process and
parse the message. There is no need to link any CIDs between SIP headers
and body parts in order to figure out what to do.

So, by using C-T for info packages it will work ecactly the same way for
INFO. I look at C-T, and I process and parse the info package body part.
Simple.

>BTW, it's not that I disagree with you that content-types to date have
been unambiguous in reality.  They have, afaik.  And I think we would be
well-advised to keep future extensions from re-using 
>already defined C-T's if ambiguity could occur.  For most things we're
pretty safe.  For example, any future Info package would be safe to
re-use existing C-T's, because a negotiation mechanism is in 
>place to indicate package support, so you wouldn't get a message with
the package to begin with if you didn't understand it and support
disambiguating body parts.

I just think it is very useful and simple to able to look at the C-T
value in order to figure out what is in the body part...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Dec 2008 21:38:21 -0500

> Sent: Saturday, December 06, 2008 4:09 PM
> >

Geoloc may be transported in any SIP request, afaik - except ACK and CANCEL.  Putting a body in any/all messages which is not for the context of the message is not without precedent, I've been told.  Maybe this is just the first time that we really expect it to be used? :)

A content type of "application/sdp" can be used in any request that can carry mime bodies as far as I know.  It just wouldn't make sense to make it's C-D "session" in anything but INVITE, ACK, PRACK, and UPDATE; and for the SUB/NOT/PUB you'd have to define a package for using it.

BTW, CANCEL can't carry any body, afaict, if for no other reason than the Content-* headers needed to do so can't be used in CANCEL. (nor would we want it to be able to, for obvious reasons)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Dec 2008 21:57:22 -0500

> "app/sdp". You need to know what is in the body, so you can process and

Of course, but the C-T helps you determine exactly what you just described: the parsing of it.  Not the parsing of the SIP message, but the parsing of that specific body part's content; and not the purpose of that body part either - that's C-D essentially.  The SIP stack may have no idea how that content is parsed whatsoever.  All it needs to know is what upper-layer logic to pass it up to.  We're not preventing an integrated stack from processing it all at once - we're just continuing to allow a layered stack to separate it out.

So let's take the SDPng example - let's ignore that INVITE basically has special handling of session descriptions in particular, and is generally "special" in SIP for lots of things, which make the example not really applicable for the discussion.  So instead assume it's possible to handle it exactly as other messages could handle their body parts.

Just the C-D of "session" tells the SIP stack the body-part's purpose/semantic is to describe a session.  It could actually stop right there, and pass it up to a common process which handles all session descriptions, which would figure out how to parse an "application/sdpng".  Or the stack could have information about what formats the process can handle, which are just opaque strings to it, and thus determine that "application/sdpng" is not a type the process can handle and reject it right then.  Or the stack could even know how the content handled by the app process should be formatted, and reject them if they're not right.  Or the session description handling could be completely integrated into the stack.

> containded in a specific body part. C-T can do that, as it does for XML.

But C-T does NOT do that for XML.  I can use an application/pidf+xml for any number of things.  The C-D tells me the semantic purpose of it.  I.e., what to do with it.
And again, a "package" is NOT contained in a body part.  A package may define body part content-types to use, or none at all.
The way you can know what body-parts are for the package is by those body-parts that have a C-D of "render" (unless the package defines a specific C-D value).  And since "render" is implicit/default, you don't even need to include C-D in the message.  Neat and tidy. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Dec 2008 22:59:27 -0500

This is just rehashing the discussion from many months ago on this list about doing use-specific content-types which drove us to the package header to begin with.  Please don't make us go there again! (pretty-please!)

What does it matter to you where the package identifier is, in C-T vs. Info-Package?  Most of us feel it's a lot cleaner to keep them separate, and to put the package identifier in a SIP header vs. a MIME one.

-hadriel

> Sent: Saturday, December 06, 2008 4:37 PM
> Subject: RE: [Sip] multiple bodies in any SIP message
>
>
> Hi,
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 7 Dec 2008 07:15:55 +0100

Fine, let's keep them separate. 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Sunday, December 07, 2008 5:59 AM
To: Christer Holmberg; Dean Willis
Cc: SIP List; Paul Kyzivat
Subject: RE: [Sip] multiple bodies in any SIP message

This is just rehashing the discussion from many months ago on this list
about doing use-specific content-types which drove us to the package
header to begin with.  Please don't make us go there again!
(pretty-please!)

What does it matter to you where the package identifier is, in C-T vs.
Info-Package?  Most of us feel it's a lot cleaner to keep them separate,
and to put the package identifier in a SIP header vs. a MIME one.

-hadriel

> message type you do it to, but then you have to reproduce that code 
> for all message types anyway.
>
> If we have a package specific C-T value we probably don't even need 
> the Info-Package header. So, absolutely no reason to link a header 
> with a body part, because there is no header. Just like SDP.
>

> problem I am not sure we all agree what it is, fine. If needed, you 
> can then use that solution also for your info package body parts.
>
> >>Because, in most cases today clients are able to find out what is in

> >>a
> they're doing from a wireshark trace, but what 3261 says is that in 
> fact there is a C-D that extends the C-T.  It just happens to be

> actually doing it right.
>
> In my experience, the problem is not "context", because it is know 
> what information is sent in what message. In addition, C-T (together 
> with C-D if you like) tells you what a body part contains, so you can 
> process and parse the message. There is no need to link any CIDs 
> between SIP headers and body parts in order to figure out what to do.
>
> So, by using C-T for info packages it will work ecactly the same way 
> for INFO. I look at C-T, and I process and parse the info package body
part.
> been unambiguous in reality.  They have, afaik.  And I think we would 
> be well-advised to keep future extensions from re-using

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 7 Dec 2008 07:18:08 +0100

>The C-D tells me the semantic purpose of it.  I.e., what to do with it.
>And again, a "package" is NOT contained in a body part.  A package may
define body part content-types to use, or none at all.
>The way you can know what body-parts are for the package is by those
body-parts that have a C-D of "render" (unless the package defines a
specific C-D value).  And since "render" is implicit/default, you 
>don't even need to include C-D in the message.  Neat and tidy. :)

So, there is no problem then. Let's move on.

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 7 Dec 2008 14:03:01 +0100

Hi, 

>>reliable provisional response or a 2xx response, 488 isn't available 
>>to you (except I suppose you could put a Reason header in the PRACK or

>>ACK request, but I don't really want to go there).
>
>The same could be said of 413, 415, 493, etc.  If the UAC can't
fundamentally handle an INVITE response's body, it can send a CANCEL,
with the Reason header.  I thought that was the point of the Reason 
>header - to be able to send the failure reason in requests.
>From RFC 3326:
>So I don't think we need we need a way of indicating in an INFO 
>response problems with body content in the request.  Let the 
>application send an INFO request in the reverse direction.
>
>That's not always technically possible, AFAICT.  If the body content is
bad, there's no guarantee it even got to the app-layer.

If the body content is bad, in the sense that the UA does not support
it, can't parse it etc, one should be allowed to send a 4xx response -
like for any other SIP request (well, not for PRACK, but we're trying to
fix that :).

BUT, if the body is used for my chess application, and I am trying to
make a chess move which is not allowed, that should not be mapped into a
SIP response code. Instead an INFO should be sent back, indicating the
error.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 7 Dec 2008 14:03:12 +0100

Hi,

I agree with Dean. The SIP stack should be allowed to send 4xx in order
to say "call does not exist", "I don't support this content-type", "I
don't support this info package" etc.

But, we should not try to map specific info package application level
errors into SIP response codes.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Friday, December 05, 2008 6:32 PM
To: Elwell, John
Cc: SIP List; Paul Kyzivat; DRAGE,Keith (Keith)
Subject: Re: [Sip] INFO Framework - one pakage per INFO

Which is why the SDP response should have been in a request sent back
from terminating UA to originating UA, and not in an answer. But that
cat and most of its relatives are out of the bag, at least for SIP 2.0.
Note for posterity: you can't fix a broken leg with a band-aid well
enough for running on, but if you add enough band-aids, you just might
make a squishy-sticky prosthetic that lets you limp along.

I concur. It might be reasonable for the SIP stack to send a 4xx
response meaning "I have no idea what to do with this INFO body; I
either don't understand it, or I have no application to hand it to".  
Beyond that, it just isn't SIP's job to express application semantics in
a response code.

---

From: Eric Burger <[email-masked]>
Date: Sun, 7 Dec 2008 11:04:57 -0500

*IF* we were to do multiple Info Packages in an INFO request, then the  
UAC is SOL if one package succeeds and another fails. That is the  
current text.

HOWEVER, I thought consensus was one Info Package per INFO request.

BTW, 20 pages for INFO is OK, as most of the text is a dissertation on  
why we are doing what we are doing. Remember, this is the merge of not  
one, not two, but THREE documents. Get over it ;-)

You know, we just passed 300 messages on THIS version of the INFO  
draft. I was going to wait for the traffic to die down before doing  
the next revision. Wonder when that will be? Soon, I hope.

On Dec 4, 2008, at 7:43 PM, Hadriel Kaplan wrote:

>> Of Dean
>>> would
> Let's imagine, for sake of argument, that the solution to the  
> general SIP message problem of dis-ambiguating body parts which  
> don't belong to the message context, were to be solved by creating a  
> CID for all the body-parts that *did* belong to the message  
> context.  I think that would be incredibly foolish, maybe even  
> pathological, but let's just pretend that we decided it was the  
> right solution... (nice setup, eh? :)
> Would we:
> a) Put the CID URL in specific SIP headers unique to each message  
> type, for example "Info-Package:", "Event:", "Invite-cid:", "Message- 
> cid:", etc.?
> Now I would claim that any sane human would go with option (b),  
> thereby nixing multiple Info-Packages to begin with. (and oh by the  
> way showing why we shouldn't try to solve this for Info only)
> Then someday in the future we define Info-Packages "Foo" and "Bar".   
> I send them both in an INFO.  I get a 400 back.  Which one failed?   
> One of them could be a critical type, with app-level failure maybe  
> decide it's really important and needs a special SIP header for it  
> too in the INFO request.  Like, oh, I don't know... a header called  
> imagination!)  Which package would this header belong to?  I mean,  
> my god there could be another future package which needs that same  
> header too!  Would we create a "Header-ID" param and HID URL too??
>
> -hadriel

---

From: "Mary Barnes" <[email-masked]>
Date: Sun, 7 Dec 2008 11:33:30 -0500

I haven't chimed in yet, but I too cannot see why this debate continues.
As someone whosedone lots of SW development in the past, I see the
complexity of more than one INFO package per request to introduce far
more potential for complexity than "One INFO package per INFO request".
It seems to be an extremely small minority that seems to think the added
complexity is worth saving some messages. 

I agree there may be some interfaces over which saving bits is very
important - in that case, in the past, I've done "message bundling" by
including more than one message across the wire at one time. BUT, that
was done at a lower layer, entirely transparent to the S/W that
generates the basic messages. ISTM that the burden should be on the
interfaces with the limitations rather than across the board for all
usages of INFO packages - i.e., I don't see this at all to be an INFO
package issue. That all said, if there is some correlation/coupling of
the two packages by the application, then perhaps you should define a
single new package that combines the information - it seems then that
the implementation would be significantly simpler.   

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Burger
Sent: Sunday, December 07, 2008 10:05 AM
To: Hadriel Kaplan
Cc: SIP List
Subject: Re: [Sip] INFO Framework - one pakage per INFO

You know, we just passed 300 messages on THIS version of the INFO draft.
I was going to wait for the traffic to die down before doing the next
revision. Wonder when that will be? Soon, I hope.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Dec 2008 11:45:27 -0500

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Sunday, December 07, 2008 11:34 AM
>
> ... That all said, if there is some correlation/coupling of

Right, that's what we said when people asked how to do two things that really have co-dependence and cannot be separated because they're not atomic actions.  Just define a package that has both of those things in it.  A "molecule" so to speak. :)

There's no reason a single package can't have multiple body-parts, for example.  Just like SUB/NOT/PUB packages can.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Dec 2008 11:49:14 -0500

> From: Eric Burger [mailto:[email-masked]]
> Sent: Sunday, December 07, 2008 11:05 AM
>

Yup.

> one, not two, but THREE documents. Get over it ;-)

I'm ok with it (I am hardly in a position to complain about verbosity).  But I do think some of the current text belongs in an appendix, not the main section.  But that's just an editorial comment and we can do that later once we agree on the basics. :)

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 7 Dec 2008 18:36:39 +0100

Hi,

Please take a look at the "read this first" mail I sent. At least I am
ok with one package per INFO, assuming we remove all the CID stuff from
the draft, and that a single package can have multiple body-parts.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Sunday, December 07, 2008 6:45 PM
To: Mary Barnes; Eric Burger
Cc: SIP List
Subject: Re: [Sip] INFO Framework - one pakage per INFO

> ... That all said, if there is some correlation/coupling of the two 
> packages by the application, then perhaps you should define a single 
> new package that combines the information - it seems then that the 
> implementation would be significantly simpler.

Right, that's what we said when people asked how to do two things that
really have co-dependence and cannot be separated because they're not
atomic actions.  Just define a package that has both of those things in
it.  A "molecule" so to speak. :)

There's no reason a single package can't have multiple body-parts, for
example.  Just like SUB/NOT/PUB packages can.

-hadriel

---

From: "Mary Barnes" <[email-masked]>
Date: Sun, 7 Dec 2008 12:34:42 -0500

Yes, I saw Hadriel's response and realized I had missed that one - for
most folks the volume of emails flying by on this topic has been too
much to keep up. So, sorry if what I said might have been redundant, but
it at least adds another view to the ping pong match. 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Sunday, December 07, 2008 11:37 AM
To: Hadriel Kaplan; Barnes, Mary (RICH2:AR00); Eric Burger
Cc: SIP List
Subject: RE: [Sip] INFO Framework - one pakage per INFO

Hi,

Regards,

Christer 

-----Original Message-----

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 9 Dec 2008 00:25:02 +0100

> That's not always technically possible, AFAICT.  If the body 
> content is bad, there's no guarantee it even got to the app-layer.
> 

Now you are getting really confused on layers. These are the circumstances where the correct error is 4xx - 6xx indicating that the SIP level was unable to deliver to the application.

regards

Keith 

> Sent: Friday, December 05, 2008 3:31 PM
> To: Elwell, John; Paul Kyzivat; DRAGE, Keith (Keith)
> Cc: SIP List
> The same could be said of 413, 415, 493, etc.  If the UAC 
> can't fundamentally handle an INVITE response's body, it can 
> send a CANCEL, with the Reason header.  I thought that was 
> the point of the Reason header - to be able to send the 
> failure reason in requests.
> From RFC 3326:
> That's not always technically possible, AFAICT.  If the body 
> content is bad, there's no guarantee it even got to the app-layer.
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Dec 2008 18:45:39 -0500

> Sent: Monday, December 08, 2008 6:25 PM
>
> Now you are getting really confused on layers. These are the circumstances
> where the correct error is 4xx - 6xx indicating that the SIP level was
> unable to deliver to the application.

Ummm... no, that was the point *I* was making. :)

> > application send an INFO request in the reverse direction.

And I said that's not always possible - the app layer may have no idea about a malformed body content arriving.  We need to allow 4xx-6xx to be body *content* formatting errors too.  I.e., if you send me an INFO for a package "myXml" with body-part of C-T "application/xml" and that body-part's content is in fact just the string ":-P", I should be able to respond with a 4xx.  The question is what the xx should be.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 9 Dec 2008 11:44:16 +0100

Hi,

Let's assume that it will take some time to process the body content -
and may then figure out that something is wrong with it.

But, on SIP level everything went fine, so you should send 200 (OK) for
the INFO, and not wait for the application to process the body content
first.

Then, if the application finds out that something is wrong (on an
application level) with the body content, it should send a separate INFO
to indicate that.

But, if the body content e.g. contains non-allowed characters, and can't
be parsed, the SIP stack can of course reject the INFO.

Regards,

Christer

> Sent: 9. joulukuuta 2008 1:46
> To: DRAGE, Keith (Keith); Elwell, John; Paul Kyzivat
> Cc: SIP List
> > > That's not always technically possible, AFAICT.  If the 
> body content 
> > > is bad, there's no guarantee it even got to the app-layer.
> > >
> >
> > Now you are getting really confused on layers. These are the 
> > circumstances where the correct error is 4xx - 6xx 
> indicating that the 
> > SIP level was unable to deliver to the application.
> 
> And I said that's not always possible - the app layer may 
> have no idea about a malformed body content arriving.  We 
> need to allow 4xx-6xx to be body *content* formatting errors 
> too.  I.e., if you send me an INFO for a package "myXml" with 
> body-part of C-T "application/xml" and that body-part's 
> content is in fact just the string ":-P", I should be able to 
> respond with a 4xx.  The question is what the xx should be.
> 
> -hadriel

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 9 Dec 2008 11:06:52 -0000

Alternatively you could say that 200 OK meant that the application had 
accepted, but not necessarily processed it.  As part of accepting a message, 
the application could sanity check it.  That would allow things like 
malformed messages and other such lower layer machinery to be handled in a 
common way.  Otherwise you presumably have to define how malformed messages, 
and a whole bunch of other error conditions, are handled for every single 
INFO package.  It also allows the application the option to process the 
message then and there, which will likely simplify a lot of INFO exchanges, 
especially if INFO is allowed a response body.

Regards,

Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
=============================================

----- Original Message ----- 
From: "Christer Holmberg" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>; "DRAGE, Keith (Keith)" 
<[email-masked]>; "Elwell, John" <[email-masked]>; "Paul 
Kyzivat" <[email-masked]>
Cc: "SIP List" <[email-masked]>
Sent: Tuesday, December 09, 2008 10:44 AM
Subject: Re: [Sip] INFO Framework - one pakage per INFO

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 9 Dec 2008 12:42:39 +0100

Hi, 

>Alternatively you could say that 200 OK meant that the 
>application had accepted, but not necessarily processed it.  

I guess we are going into implementation details, but I think that if
the message SIP syntax wise is correct, the package has been negotiated
etc, the SIP stack should be able to handle it over to the application
and send 200 (OK). It should not need to wait for any information back
from the application before sending the response.

>As part of accepting a message, the application could sanity 
>check it.  That would allow things like malformed messages 
>and other such lower layer machinery to be handled in a 
>common way.

Correct.

>Otherwise you presumably have to define how malformed messages, and a
whole bunch of other error 
>conditions, are handled for every single INFO package.  It also allows
the application the option to process the message 
>then and there, which will likely simplify a lot of INFO exchanges,

Malformated INFOs should be hanlde like any other malformed SIP method. 

Regards,

Christer

> <[email-masked]>; "Elwell, John" 
> <[email-masked]>; "Paul Kyzivat" <[email-masked]>
> > But, on SIP level everything went fine, so you should send 200 (OK) 
> > for the INFO, and not wait for the application to process the body 
> > content first.
> >
> > application level) with the body content, it should send a separate 
> > INFO to indicate that.
> >
> > But, if the body content e.g. contains non-allowed characters, and 
> > can't be parsed, the SIP stack can of course reject the INFO.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >> And I said that's not always possible - the app layer may have no 
> >> idea about a malformed body content arriving.  We need to allow 
> >> 4xx-6xx to be body *content* formatting errors too.  I.e., if you 
> >> send me an INFO for a package "myXml" with body-part of C-T 
> >> "application/xml" and that body-part's content is in fact just the 
> >> string ":-P", I should be able to respond with a 4xx.  The 
> question 
> >> is what the xx should be.
> >>
> >> -hadriel

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 9 Dec 2008 13:15:26 -0000

Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ for more info
=============================================

----- Original Message From: "Christer Holmberg"

> Malformated INFOs should be hanlde like any other malformed SIP method.

But only the application (and not the SIP layer) knows whether it is 
malformed or not.  So the SIP layer needs to ask the application whether it 
will accept the message before giving a response.

Pete

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 9 Dec 2008 13:27:24 -0000

Ooops - sorry about the formatting.  Forgot to scroll up when I finished 
editing the message!

----- Original Message ----- 
From: "Pete Cordell" <[email-masked]>
To: "Christer Holmberg" <[email-masked]>; "Hadriel Kaplan" 
<[email-masked]>; "DRAGE, Keith (Keith)" <[email-masked]>; 
"Elwell, John" <[email-masked]>; "Paul Kyzivat" 
<[email-masked]>
Cc: "SIP List" <[email-masked]>
Sent: Tuesday, December 09, 2008 1:15 PM
Subject: Re: [Sip] INFO Framework - one pakage per INFO

> malformed or not.  So the SIP layer needs to ask the application whether 
> it will accept the message before giving a response.
>
> Pete
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Dec 2008 10:08:52 -0500

Pete Cordell wrote:
> accepted, but not necessarily processed it.  As part of accepting a 
> message, the application could sanity check it.  That would allow things 
> like malformed messages and other such lower layer machinery to be 
> handled in a common way.  Otherwise you presumably have to define how 
> malformed messages, and a whole bunch of other error conditions, are 
> handled for every single INFO package.  It also allows the application 
> the option to process the message then and there, which will likely 
> simplify a lot of INFO exchanges, especially if INFO is allowed a 
> response body.

I think the distinction drawn here can be signaled using 200 or 202.
If the body has been parsed and is known to be valid return 200, whether 
it has been acted upon or not. If it has not been verified to have valid 
syntax, return 202.

	Thanks,
	Paul

> ----- Original Message ----- From: "Christer Holmberg" 
> <[email-masked]>
> <[email-masked]>; "Elwell, John" <[email-masked]>; 
> "Paul Kyzivat" <[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Dec 2008 13:54:51 -0500

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Tuesday, December 09, 2008 8:15 AM
>
> it

That's not necessarily true.  I could have a firewall-type checker in the SIP layer that verifies XML syntax is valid, which knows nothing about the semantics of the elements/attributes themselves, before passing it on to an app layer.

And before anyone says "but we can't require it to do so and we have to accommodate a layered model only understanding the content in the app-layer" - that's NOT the issue.  Of course we have to allow for only the app-layer understanding content - we should even *assume* it.

But the reality is that we already allow a 4xx response to be sent for a bunch of sip-layer error reasons.  Because of that, the app-layer *sender* of an INFO request has to accommodate "delivery-failure" based on a 4xx response already.  Period.  Therefore, an _integrated_ model *receiver* would simply send one of those 4xx responses if it failed content formatting error checks when it receives an INFO request, because from a functional app-layer perspective to the INFO *sender* it is no different than a delivery-failure.  There is nothing we can do to stop that behavior, because there's nothing broken with that behavior, either in terms of interop or semantics.  We can try to say "even if the content is malformed you MUST send back 200 and then a new INFO with an error code", but that will be summarily ignored.

So the question is simply if we want a specific response code for content formatting errors, such as 488, to help troubleshooting - or if they should just send 400 or 415 as they do today.  Again, this doesn't prevent a fully layered model from sending 200 back and then some INFO request upstream with an error code - it just makes it easier to troubleshoot what an integrated model can already do by sending back a 400 or 415.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Dec 2008 14:25:13 -0600

On Dec 9, 2008, at 12:54 PM, Hadriel Kaplan wrote:

> That's not necessarily true.  I could have a firewall-type checker  
> in the SIP layer that verifies XML syntax is valid, which knows  
> nothing about the semantics of the elements/attributes themselves,  
> before passing it on to an app layer.

It had damn well better do that only for an application/xml body type.  
If it sees something that sort of looks like XML and then tries to  
check it (and it isn't really XML), we're back to coupling  
applications to the SIP protocol (or worse yet, to the SBC . ..)
>
>
> So the question is simply if we want a specific response code for  
> content formatting errors, such as 488, to help troubleshooting - or  
> if they should just send 400 or 415 as they do today.  Again, this  
> doesn't prevent a fully layered model from sending 200 back and then  
> some INFO request upstream with an error code - it just makes it  
> easier to troubleshoot what an integrated model can already do by  
> sending back a 400 or 415.

I would say it as something like "If the UAS cannot decode the MIME  
structure of the body because of formatting errors, it returns a 606.  
If the UAS can decode the MIME structure of the body but does not know  
what to do with the body parts, either because they are of an  
unrecognized type or because there is no application to consume those  
body parts, the UAS returns a 415. Otherwise, the UAS delivers the  
body part to the application and returns a 200 OK."

I would leave discussion of application-level rejection of body parts  
entirely out of the discussion.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Dec 2008 18:38:04 -0500

> Sent: Tuesday, December 09, 2008 3:25 PM
>

Sounds fine with me.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Dec 2008 18:56:45 -0500

>> entirely out of the discussion.

This seems to make it *incorrect* to return any error response in the 
case where the content of the body is incorrect. (For instance if the 
syntax of the body part is inconsistent with the Content-Type declared 
for that part.

While I am ok with *allowing* the UAS to return a 200 in this case, I 
think we go too far to say they UAS MUST NOT return an error for this 
situation.

OTOH, none of the above is normative language, so perhaps the whole 
thing is to be construed as a recommendation or note? I find it very 
difficult after the fact to interpret such language. I would rather that 
it be very explicit about what is normative and what is not intended to be.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Dec 2008 19:01:31 -0500

No I read "...either because they are of an unrecognized type..." to be inclusive of body content format.  It does not say "...of an unrecognized *Content-Type*".  I get to choose what "type" means for me.
:)

-hadriel

> Sent: Tuesday, December 09, 2008 6:57 PM
>
> Hadriel Kaplan wrote:
> >

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Dec 2008 19:35:45 -0600

On Dec 9, 2008, at 5:56 PM, Paul Kyzivat wrote:
>
> This seems to make it *incorrect* to return any error response in  
> the case where the content of the body is incorrect. (For instance  
> if the syntax of the body part is inconsistent with the Content-Type  
> declared for that part.
>

If the syntax is correct enough for the MIME layer t decode the  
object, SIP is happy.

For example, let;s say it is an image/jpeg of your girlfriend. If the  
SIP Stack can unpack the image/jpeg from the MIME, SIP is happy. If it  
turns out to be a bad picture of your girlfriend and makes her look  
like the clown from "It", that's not SIP's problem. If it's actually  
an image/gif with an erroneous image/jpeg tag on it, that's also not  
SIP's problem.

> While I am ok with *allowing* the UAS to return a 200 in this case,  
> I think we go too far to say they UAS MUST NOT return an error for  
> this situation.

I'm thinking this should be normative, actually. If it's an error that  
SIP can't detect, reporting it as a SIP error seems bogus. If we have  
to have application-driven errors, we probably need a new response code.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 10 Dec 2008 00:10:49 -0500

> Sent: Tuesday, December 09, 2008 8:36 PM
>

Devices already do report mime body *content* errors in SIP responses. That's what a 488/606 really is, for example, for SDP.  And some devices already respond with 415 due to malformed body content of other types.

There's actually nothing wrong with that, from a semantics perspective - they're telling you your request failed to be delivered due to a body error, and it's true.  And there's no interop issue either.  Your code already has to be able to handle a failure response for that delivery attempt, and handle it as a delivery failure, and tell your app-layer about that delivery-failure.

The only questions, really, are:
1) Do we need to define in the base INFO doc how to handle app-layer failures using separate upstream INFO requests.  For example, do we need to define how malformed document errors are reported in upstream INFO messages.  I don't think we do, because I think it's only a subset of packages that would ever care, and they'd probably need their own semantics and syntax for what they care about and what it means to them.  So there's no need to pollute the base doc with that.

2) Can we allow app-specific failures in INFO responses, for example do we allow packages to define specific response codes and bodies which can be used in responses; or do we only allow bodies and package-specific responses in INFO requests. (or option C is laissez-faire, and debate it in package definitions - as PUBLISH does essentially)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Dec 2008 00:20:18 -0600

On Dec 9, 2008, at 11:10 PM, Hadriel Kaplan wrote:

> e.
> 1) Do we need to define in the base INFO doc how to handle app-layer  
> failures using separate upstream INFO requests.  For example, do we  
> need to define how malformed document errors are reported in  
> upstream INFO messages.  I don't think we do, because I think it's  
> only a subset of packages that would ever care, and they'd probably  
> need their own semantics and syntax for what they care about and  
> what it means to them.  So there's no need to pollute the base doc  
> with that.
>

Define "malformed document error". Do you mean garbled MIME, or a body  
that extracts for MIME but isn't valid for its content-type? Or do you  
mean a body that is valid for it's content-type, but subject to higher- 
level evaluation that it fails (for example, it's valid-looking XML,  
but it fails the schema verification).

> 2) Can we allow app-specific failures in INFO responses, for example  
> do we allow packages to define specific response codes and bodies  
> which can be used in responses; or do we only allow bodies and  
> package-specific responses in INFO requests. (or option C is laissez- 
> faire, and debate it in package definitions - as PUBLISH does  
> essentially)

I think it would be deeply stupid to have a package definition define  
a new SIP response code. Just because we messed up and got our  
transport confused with our application in the past doesn't mean we  
should keep repeating that mistake mindlessly.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 10 Dec 2008 01:42:17 -0500

> Sent: Wednesday, December 10, 2008 1:20 AM
>

Yes, all of the above.  It fails formatting syntax rules, not semantics. (And schema validation I think of as formatting rules)  If it's gzip and it doesn't decompress, for example.

I don't think we need to define a specific upstream INFO request mechanism to indicate such a failure.  If a package cares about such things, it can define one, since it will probably need other real app-layer error indications anyway.  For example KPML went to the trouble of doing that.  Most wouldn't care, I think.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Dec 2008 01:01:44 -0600

On Dec 10, 2008, at 12:42 AM, Hadriel Kaplan wrote:

>>> ...
> Yes, all of the above.  It fails formatting syntax rules, not  
> semantics. (And schema validation I think of as formatting rules)   
> If it's gzip and it doesn't decompress, for example.
>

I'm worried that people are going to take this as evidence that the  
SIP Stack SHOULD go to great lengths to validate content. For example,  
are we going to require every SIP UA have HTTP so that it can retrieve  
XML schemae, and an XML validtory to check body parts with, and then  
validate every XML body part before handing it ti the application?  
What response code should SIP send if a body part un-MIMEs ok, but the  
SIP UA can't find the schema needed to validate the body? What if some  
application data used invalid XML in his body?

I'd really rather not have this as protocol considerations for SIP.  
The SIP stack has to be able to pull the content out of its (possibly  
multipart) MIME wrapper. If the MIME wrapping is good and there's an  
application to hand the payload off to, I think SIP should be happy to  
send a 200 OK.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 10 Dec 2008 02:30:20 -0500

> Sent: Wednesday, December 10, 2008 2:02 AM
>

Of course it should.  I think you're missing the point (or I'm missing yours) - there's no debate that we have to allow a SIP request with valid SIP-layer stuff and valid mime wrapper and all be responded to with a 200 ok.  Or at least I'm not debating that.  It would be silly to mandate a SIP stack to do any more than that.  But I also think we really shouldn't explicitly disallow me to send you back a 4xx.  It's a non-sequitur.  I can send a 4xx anyway, and as long as the resultant behavior is the same, who's the wiser?  I have really not delivered it to an app-layer; there is no recovering from this condition (it's not like you can programmatically re-format it and hope this time I understand it); and whatever action you take due to a delivery-failure is really the right action to take in this case too.

I think your point is that we shouldn't explicitly point this out, for fear of people thinking they need to do it?  So that rules out creating a new specific response code for it, and just letting 415 or 400 cover that case.  (that's essentially what all the other SIP specs do too - don't mention it, leave it implementation specific)  I don't see people having interop issues with it so that's fine, though it makes troubleshooting a bit more laborious.

-hadriel

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 09 Dec 2008 23:49:01 -0800

I think we should just be honest and admit that we're doing no one any 
favors by being very dogmatic about layering here. At the end of the day 
SIP is not a transport protocol. Who says we need to be so strict about 
separating SIP from app.

So Hadriel, I guess I agree with your conclusion but I agree with Dean 
that it really is a layer violation. I just don't see it as such a big deal.

Anders

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Dec 2008 08:35:46 -0500

I agree with Handriel and Anders.

The distinction that Dean is trying to draw is a very fuzzy one when you 
dig into it. Remember that a multipart is also just a body type, and 
taking it apart is body processing. We could argue that the specific 
degree of multipart parsing that is required to identify the individual 
elements is required in order to respond to the sip message, but parsing 
of other parts, even other multipart parts is not, and so failures there 
must not be reported. But then what about a stack that decomposes the 
entire tree of multiparts first and then deals out the parsed parts to 
the "invite" application and the other applications? What if there is a 
multipart/alternative with C-D of "session"? Is it ok to return a 488 if 
that can't be decomposed into its contained parts, or a 415 if the 
contained parts don't contain SDP?

I think we need to work this so there is some latitude for how the 
application layers the processing.

	Thanks,
	Paul

Anders Kristensen wrote:
>> Of course it should.  I think you're missing the point (or I'm missing 
>> yours) - there's no debate that we have to allow a SIP request with 
>> valid SIP-layer stuff and valid mime wrapper and all be responded to 
>> with a 200 ok.  Or at least I'm not debating that.  It would be silly 
>> to mandate a SIP stack to do any more than that.  But I also think we 
>> really shouldn't explicitly disallow me to send you back a 4xx.  It's 
>> a non-sequitur.  I can send a 4xx anyway, and as long as the resultant 
>> behavior is the same, who's the wiser?  I have really not delivered it 
>> to an app-layer; there is no recovering from this condition (it's not 
>> like you can programmatically re-format it and hope this time I 
>> understand it); and whatever action you take due to a delivery-failure 
>> is really the right action to take in this case too.
>>
>> I think your point is that we shouldn't explicitly point this out, for 
>> fear of people thinking they need to do it?  So that rules out 
>> creating a new specific response code for it, and just letting 415 or 
>> 400 cover that case.  (that's essentially what all the other SIP specs 
>> do too - don't mention it, leave it implementation specific)  I don't 
>> see people having interop issues with it so that's fine, though it 
>> makes troubleshooting a bit more laborious.
>>
>> -hadriel
>>

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Dec 2008 10:45:48 -0600

On Dec 10, 2008, at 1:30 AM, Hadriel Kaplan wrote:
>
> I think your point is that we shouldn't explicitly point this out,  
> for fear of people thinking they need to do it?  So that rules out  
> creating a new specific response code for it, and just letting 415  
> or 400 cover that case.  (that's essentially what all the other SIP  
> specs do too - don't mention it, leave it implementation specific)   
> I don't see people having interop issues with it so that's fine,  
> though it makes troubleshooting a bit more laborious.
>

I think I agree.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Dec 2008 15:48:35 -0600

Sorry for the slight deviation from topic, but its probably worth re- 
highlighting here
that CANCEL is hop-hop and isn't capable of carrying information end- 
end (like what
you'd expect to see when using SDP). ACK-non200 is similar.

RjS

On Dec 6, 2008, at 8:38 PM, Hadriel Kaplan wrote:

> Geoloc may be transported in any SIP request, afaik - except ACK and  
> CANCEL.  Putting a body in any/all messages which is not for the  
> context of the message is not without precedent, I've been told.   
> Maybe this is just the first time that we really expect it to be  
> used? :)
>
> A content type of "application/sdp" can be used in any request that  
> can carry mime bodies as far as I know.  It just wouldn't make sense  
> to make it's C-D "session" in anything but INVITE, ACK, PRACK, and  
> UPDATE; and for the SUB/NOT/PUB you'd have to define a package for  
> using it.
>
> BTW, CANCEL can't carry any body, afaict, if for no other reason  
> than the Content-* headers needed to do so can't be used in CANCEL.  
> (nor would we want it to be able to, for obvious reasons)
>
> -hadriel