Adam Roach wrote:
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.
That indeed is the way I was reading it. At the least it needs to be
clarified
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.
I'm still not sure that covers all the valid cases, though again it may
be a matter of parsing the words.
Lets take a concrete example:
1) A usage for location-convenance (trimmed for readability):
INVITE sips:[EMAIL PROTECTED] SIP/2.0
To: Bob <sips:[EMAIL PROTECTED]>
From: Alice <sips:[EMAIL PROTECTED]>;tag=9fxced76sl
Call-ID: [EMAIL PROTECTED]
Geolocation: <cid:[email protected]>
;[EMAIL PROTECTED] ;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sip:[EMAIL PROTECTED]>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP goes here
--boundary1
Content-Type: application/pidf+xml
Content-ID: [EMAIL PROTECTED]
<?xml version="1.0" encoding="UTF-8"?>
... bunch of presence stuff
--boundary1--
2) Alice sends a REFER to Bob. As a result, Bob sends an
INVITE to Charlie. Charlie's response contains an
Alert-Info header with a CID URL. Bob wants Alice to
know about this, so he sends the entire response in
the NOTIFY for the refer event package:
NOTIFY sip:alice.atlanta.example.com SIP/2.0
To: <sip:[EMAIL PROTECTED]>;tag=193402342
From: <sip:[EMAIL PROTECTED]>;tag=4992881234
Event: refer
Subscription-State: active;expires=600
Content-Type: message/sipfrag;version=2.0
Content-Length: ...
SIP/2.0 200 OK
To: <sip:[EMAIL PROTECTED]>;tag=876402342
From: <sip:[EMAIL PROTECTED]>;tag=4992881235
Alert-Info: <CID:[email protected]>
Call-ID: [EMAIL PROTECTED]
CSeq: 182 INVITE
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP goes here
--boundary1
Content-Type: audio/mpeg
Content-ID: [EMAIL PROTECTED]
... bunch of mpeg stuff here
--boundary1--
I think your interpretation covers (1). But in (2) it is a header in the
*body* of the notify that contains a reference to one of the parts of
the multipart body of that body. I don't think the existing words cover
that case.
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
