On Dec 9, 2008, at 11:10 PM, Hadriel Kaplan wrote:
e.
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.
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
_______________________________________________
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
