Gonzalo,
This all sounds good. I haven't read the new version yet, but based on
your description below I have no problems with this, except possibly one
area in which I am uncertain and which I would like to discuss:
Gonzalo Camarillo wrote:
"4.2. Body Processing
UAs process message bodies and body parts in the following way. On
receiving a SIP message, if a body part is not referenced in any way
(e.g., there are no header fields or other body parts with a
Content-ID URL pointing to it), the UA processes the body part as
indicated by its disposition type and the context in which the body
part was received.
OPEN ISSUE 4: this means that a UA would need to parse all body parts
to find references between them before being able to fully process
them. If we are OK with this, we need to include text here
explaining it."
I think there is at least ambiguity about what it means to "process" a
body part. If one body part has a reference to another body part, then
some amount of processing is required to detect such a reference.
There seems to be an implication that two-pass (or more) processing,
such as is typically done in compilers, is expected. But given the
variety of body types I think it will be difficult to define what may be
processed in a first pass and what must be postponed to a second pass.
Also, often people will want to use off-the-shelf packages to support
certain body types, and those may not be so cooperative with this
requirement.
Also, whether we like it or not, there will be systems that are only
interested in a subset of what is there. (For instance proxies that are
interested in SDP for purpose of enabling access.) These will want to
parse the minimum necessary to find what they are interested in. It
would be best if we can figure out a way for this to work.
Maybe it is that a UA needs to parse everything that is supported, but
other nodes it passes through can be more selective.
OPEN ISSUE 3: do we need to talk about encrypted body parts?
???
Christer brought this one up. What did you have in mind?
Nothing. I just don't know.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www1.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
