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

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Tuesday, December 09, 2008 8:36 PM
>
> > 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.

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
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip