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: Wednesday, December 10, 2008 1:20 AM
>
> On Dec 9, 2008, at 11:10 PM, Hadriel Kaplan wrote:
> > 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).

Yes, all of the above.  It fails formatting syntax rules, not semantics. (And schema validation I think of as formatting rules)  If it's gzip and it doesn't decompress, for example.

I don't think we need to define a specific upstream INFO request mechanism to indicate such a failure.  If a package cares about such things, it can define one, since it will probably need other real app-layer error indications anyway.  For example KPML went to the trouble of doing that.  Most wouldn't care, I think.

-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