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
_______________________________________________
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
