Re: INFO Framework - one pakage per INFO

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