[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
