Re: INFO Framework - one pakage per INFO

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