-----Original Message-----
From: Gonzalo Camarillo [mailto:[email protected]]
Sent: Tuesday, December 16, 2008 4:05 AM
To: Hadriel Kaplan
Cc: Eric Burger; SIP List
Subject: Body handling - Contexts WAS (Re: [Sip] multiple bodies in any
SIP message)
Hi Hadriel,
> I think the body-handling draft already does it, although maybe I'm
> reading into it what I want to and not what it really says.
the draft already talks about contexts:
http://tools.ietf.org/html/draft-ietf-sip-body-handling-05#section-8.1
I would like to agree on a concrete way forward. Do you think we should
add something to the body handling draft? Maybe expand the information
on contexts? Maybe provide guidelines for extension developers so that
they take them into account when defining new extensions?
Thanks,
Gonzalo
Hadriel Kaplan wrote:
[note: changing the thread to be consistent]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Eric
Burger
Sent: Sunday, December 07, 2008 10:37 AM
Everyone seems to think there needs to be a generic way of
identifying
body bits.
I do not see an obvious, generic way of doing this.
Thus for those out there who think there is a generic way of
identifying body parts for SIP, please write text.
I think the body-handling draft already does it, although maybe I'm
reading into it what I want to and not what it really says.
You asked, so this email is long. This is what I think is the way
to do
it...
:Executive summary: basically we let C-D of "render" mean render to
the
specific context of the message; we mandate future extensions which are
not for that context disambiguate themselves, by not using a C-D of
"render" or the other ones already in use, and that they can't use a
C-T
already used today either. (and that includes changing geoloc's C-T
immediately)
:The Details:
Definitions:
User-context = the specific context defined by the method name, and
package if it's a method which has a package sub-context
(SUB/NOT/PUB/INF). The target user is the user-context's
app-layer. For
example an "application/dtmf-relay" body-part would want to be
targeted to
the user-context defined by the "dtmf" package in an INFO.
Method-only-context = the context defined by the method name alone,
ignoring any package. The target is the specific message
processor/state-
machine for that method, but for any/all packages/sub-contexts. For
example the Event and Subscription-State headers are for this
context in a
SUBSCRIBE. For methods that don't have a package
(INV/UPD/ACK/PRA/MSG),
the method-only-context and user-context are the same. So the
"session"
and "early-session" C-D's are really for a user-context, but it's
the same
context as method-only-context. I don't know of any bodies which are
currently only for a method-only-context.(?) Nor am I convinced we
even
need this context to be defined separately.
All-messages-context = the context is just the SIP message processing
rules common to all messages. The target is the SIP message processor
common to all SIP messages. The mandatory SIP headers (Call-ID, To,
From,
etc.) are examples of things targeted for this context. An AIB,
geoloc,
and maybe sipfrag(?) bodies are targets for this context.
Note on above: If you think of this as a layered model with an API, or
better yet a class object model - basically the all-messages-context is
for things needing to be handled/extracted in the base SIP message
class,
the method-only-context is for stuff to be handled in a derived
class for
a given method, and the user-context is for stuff to be handled by a
derived class from that for a given package, which may just be the same
class for some methods (INV/UPD/etc.).
Rules:
1) Any body-part with a C-D of "render", means to render it to the
"user" - not the human user, but the *user-context*. This lets us get
backwards-compatibility for free, because a C-D of "render" is implicit
and what current SIP messages actually have and UA's expect. That C-D
becomes the "default" so to speak, which it already is today.
2) Any package (event of info) can define additional C-D's that belong
to it, just like they can define C-T's that they support. I am not
entirely thrilled with letting packages define C-D's, but some
already do
("signal", for example). If we'd rather just grandfather those and
say no
more that's fine. ISTM that a package could get that semantic purpose
information from within the boy content itself (in XML, for example)
if it
really needs such. Methods already do too, like "session" or "early-
session". If we decide packages can have their own C-D's, then we need
additional rules not to step on body parts for others, but I'll skip
that
for now.
3) Any body-part that is NOT for the user-context, for example a
geoloc,
needs to disambiguate itself from the rest, by using a C-D other than
"render" or the ones already defined. If it needs a sub-context other
than the all-messages-context, or is in fact tied to a SIP header,
then it
needs to use CID, and a C-D of "by-reference". I would in fact suggest
that all future extensions which need to be for something other than
the
user-context MUST have a referencing SIP header and use a CID and a
C-D of
by-reference.
4) Furthermore, any future extension which is not for the user-context
MUST NOT use any C-T currently defined in any RFC or WG draft for SIP,
including already defined event-packages. That sounds harsh, but
that's
what we need to do to get a very high degree of
backwards-compatibility I
think. So this means you can't do a geoloc-type thing using
"text/plain",
for example, or really even "application/pidf+xml", which is what
geoloc
currently uses in its draft. And body-handling or some other draft
should
list all such C-T's, so future extensions can know the list to
avoid. And
if we want to just say no C-T currently define by IANA period, I'm fine
with that too. Note this does NOT prevent future SIP RFCs from
using a C-
T defined by such an extension as geoloc. For example, if geoloc uses
"application/foobar", then a future Event-package could use that too;
because that future event package would normatively reference body-
handling.
5) IF we need an option tag (and I do NOT think we do), then we should
create one and only one tag right now, for the body-handling draft's
logic. Future extensions which are not for the user-context would then
NOT need more option tags simply due to body-handling issues, but
can use
that generic one. I would also put in some extreme language into the
body-handling option tag about what it means to put such a thing in a
Require header, to dissuade people from doing that.
6) If there are some already defined things which do not follow the
above rules, we either (a) grandfather them into body-handling right
now,
or if they're not really in use, then either (b) deprecate or (c)
replace
them. (and I would vote for (b), fwiw)
-hadriel
