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
