Re: [Sip] Is body handling NP-complete?

[Dale.Worley at comcast.net]

   From: Paul Kyzivat <pkyzivat at cisco.com>

   One implication of this is that body parts need to be processed twice in 
   a content-type+content-disposition+context dependent way: once to 
   extract references, and again for final effect.

That does seem to be unavoidable in the general case.  (Though every
practical case I know of can avoid two-pass processing.)

   (Hmm - is extracting of references dependent on the disposition and
   context?)

Presumably it could be, depending on the definition of how the simple
parts are to be processed.  In any case, it doesn't seem to add
complexity to the implementation to allow for it.

   If you imagine that various content types are handled by plugins, then 
   the plugins will each require two entry points - one for each of these 
   processing modes. While that is certainly possible, it might mean that 
   plugins that already exist for non-sip applications (e.g. email or html) 
   may not be reusable for sip. (I am not familiar with the content-type 
   plugins for other protocols such as email. But I presume that email 
   plugins may be useful in some cases, at least for MESSAGE.)

   Do plugins for email have this complexity?

Since two-pass processing is required for processing the full set of
MIME constructions, plugins for e-mail processing would theoretically
have to allow this.  I've never heard of any that do.

   An alternative is to do all the processing in one pass, and then at the 
   end check if all body parts have been processed. BUT that means all the 
   side effects of processing will have been realized before discovering 
   that the message is in error. That is certainly not ideal.

It wouldn't be correct, either.  How would you process a
multipart/alternative?

   > This example also points out that the requirement that references
   > appear before the parts they reference is needed to make the problem
   > tractable.  Otherwise, there could be circular dependencies between
   > the choices for different multipart/alternatives, which might be
   > impossible to analyze by an algorithm as simple as a tree-walk.

   This requirement is satisfied by lots of simple cases. But it means that 
   it is impossible to describe any kind of circular structure. I'm not 
   familiar enough with the use of multipart/related to know if it is a 
   restriction that is tolerable there. Perhaps someone can comment on that.

The requirement is in the current I-D:

   8.2.  UA Behavior to Generate References to Message Bodies

   UAs MUST only include forward references in the SIP messages they
   generate.

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