Ed Levinson <elevinso(_at_)accurate(_dot_)com> writes:
Does one really need to make multiple passes because of Multipart/
Related's start parameter? I didn't think so. The situation that
comes to mind where that *might* be the case occurs when you process
the MIME entity on the fly. I would use the paradigm below and,
after describing it, I'll say why it introduces no *additional*
complexity.
There are two distinct parsing cases for multipart/related. One case
is when you do understand the meta-format, the other case is when you
don't understand the meta-format. In the former case, it's processed
as you describe. In the latter case, it's processed in a fashion
similar to multipart/mixed.
The problem with the start parameter is you have to scan to the start
item to decide if the bodypart is one that is understood. If it
isn't, you need to go back to the beginning and re-process in a more
multipart/mixed fashion. I note that this particular problem could be
largely remedied if the type parameter were mandatory when the start
parameter was present.
In addition, I see start as unnecessary complexity. Is there really a
case where it is necessary to put the meta-type anywhere other than
the first part? What justifies requiring the parser to do content-id
comparisons to find the start, rather than just feeding the first part
to the appropriate interpreter?
-----
Chris Newman WWW - http://www.contrib.andrew.cmu.edu/usr/cn0h/