Pete Cordell wrote:
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.
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
Regards,
Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
=============================================
----- Original Message ----- From: "Christer Holmberg"
<[EMAIL PROTECTED]>
To: "Hadriel Kaplan" <[EMAIL PROTECTED]>; "DRAGE, Keith (Keith)"
<[EMAIL PROTECTED]>; "Elwell, John" <[EMAIL PROTECTED]>;
"Paul Kyzivat" <[EMAIL PROTECTED]>
Cc: "SIP List" <[email protected]>
Sent: Tuesday, December 09, 2008 10:44 AM
Subject: Re: [Sip] INFO Framework - one pakage per INFO
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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Hadriel Kaplan
Sent: 9. joulukuuta 2008 1:46
To: DRAGE, Keith (Keith); Elwell, John; Paul Kyzivat
Cc: SIP List
Subject: Re: [Sip] INFO Framework - one pakage per INFO
> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 08, 2008 6:25 PM
>
> > 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.
Ummm... no, that was the point *I* was making. :)
Someone *else* in the email said:
> > 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.
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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
