Hadriel Kaplan wrote:
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 30, 2008 4:58 PM
Sounds ok.
But, doesn't the Info-Package header syntax still have to allow the
piggy-backer to:
1) List multiple info packages
2) For each listed info package, provide the cid
Nope. We've already said we're going to not bother doing multiple packages.
(or at least I think people have agreed with that, I hope)
So the next question was on multiple body-parts. Since INVITE, UPDATE, PRACK,
SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all carry bodies and not one of
them defined a CID mechanism for the body part that was specific to their
message method context, we shouldn't need to for INFO either.
The problem is that none of them really considered the impact of
multiple body parts, so it is anything but clear how an application is
supposed to decipher one of these messages when it does contain multiple
body parts. We are going to find that when combined with body parts for
other purposes, implementations will do a variety of things. (That
includes existing legal usages, such as body parts with C-D of "alert",
which have been defined for a long time but never used.)
The body-handling draft tries to sort this out. But based on that we
need to do better going forward than we did in the past.
Things were only "simple" in the past because we left things unspecified
that needed to be specified.
You can have your "simple" solution here, analogous to the historic
mechanism, by explicitly defining that body part(s?) with the
content-disposition of "render" are to be considered to be the
info-package payload. I say "render" because that is the *default* C-D,
so it keeps things "simple" since it can be omitted. However you then
should specify what happens if there are multiple body parts with C-D of
"render". Also, you then need to specify whether a multipart body with a
C-D of "render" should be viewed (in total) as the info-package payload,
or whether some contained part of it should be the payload.
Personally, I would rather go with something less "simple" but more
explicit here. Either a special C-D, or the CID reference.
Thanks,
Paul
A "piggy-backer" is an extension to SIP that piggy-backs bodies onto any
message method types. Geolocation is an example of one. Since it's the responsibility
of the piggy-backer to handle identifying its specific body-part and dis-ambiguating it
from the method's, we don't have to do anything. In other words, Geolocation would
already have to deal with current INFO message and body syntax.
For example, let's suppose someone creates an INFO package for sending virtual
location information in a game, using a content-type of application/pidf+xml.
(whether they should have done it in SIP vs. the media layer is orthogonal)
And let's suppose for whatever reason the SIP stack always adds Geolocation
information of the UA's physical location.
Here is what it would look like:
----BEGIN----
INFO sip:[EMAIL PROTECTED] SIP/2.0
Call-ID: [EMAIL PROTECTED]
From: <sip:[EMAIL PROTECTED]>;tag=27285
To: <sip:[EMAIL PROTECTED]>;tag=GR52RWG346-34
CSeq: 2 INFO
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
Max-Forwards: 70
Info-Package: virtual-loc
Geolocation: <cid:whereami@invalid>
Content-Length: [whatever]
Content-Type: multipart/mixed;boundary="boundary1"
--boundary1
Content-Type: application/pidf+xml
[xml stuff goes here]
--boundary1
Content-Type: application/pidf+xml
Content-Disposition: by-reference
Content-ID: [EMAIL PROTECTED]
[xml stuff goes here]
--boundary1--
----END----
_______________________________________________
Sip mailing list https://www.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
_______________________________________________
Sip mailing list https://www.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
