Hi,
yes, the sentence should be read as Adam points out. After sending the
email I noticed that adding a comma may have helped...
Thanks for the clarification,
Gonzalo
Adam Roach wrote:
On 9/5/07 8:38 AM, Paul Kyzivat wrote:
Gonzalo Camarillo wrote:
Hi,
to be more concrete in our discussions, we need to make decisions on
the following two issues:
1) Where in a SIP message is it allowed to reference a body part?
a) in header fields and body parts within the same multipart/related
as the referenced body part
b) in header fields and body parts that appear before the referenced
body part
c) in header fields and any body part
We discussed that doing c) would require to parse SIP messages twice
to look for potential references.
It is only necessary to parse twice if you can't decide what to do
with the body part without finding the reference first.
If the rule is that you *always* process a body part based on its type
and disposition, and that references provide *additional* behavior,
then you can do an initial parsing and processing without regard to
references. If the processing in that pass happens to yield references
that cannot yet be resolved, then the processing of those needs to be
deferred.
Therefore, we decided to do a) or b). The current draft specifies a),
we doing b) might make sense as well (it would be less restrictive).
We have plenty of counterexamples that (a) is insufficient. Any case
where a header field in the sip message references a body part (e.g.
GeoLocation) is a counterexample. So I think we must exclude (a) from
consideration.
I think you're misreading a). What Gonzalo proposes in a) is "IN HEADER
FIELDS and body parts within the same multipart/related as the
referenced body part"
Perhaps there's some ambiguity in the grammatical construction here. If
you read this as "(in header fields and body parts) within the same
multipart/related as the referenced body part" then you're right: this
won't work. It also makes little sense. I think that the grouping was
meant as: "(in header fields) and (body parts within the same
multipart/related as the referenced body part)".
That seems to satisfy all the existing use cases. It also prevents the
accidental specification of extensions that erroneously try to specify
related body parts without using multipart/related.
/a
_______________________________________________
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
