Hadriel,
There is good stuff in here. I've been trying to say some (not all) of
the same things, but haven't done as good of a job of it.
I'll also observe that this is the discussion I was hoping would come
out around the body-handling draft. I guess it was too abstract then,
and took a specific use case to get people thinking about it.
More (a lot more) inline...
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.
I think this teasing apart of various processing contexts is very
useful. It may need some tweaking, but certainly seems on the right
track, and maybe well town the track. This is really an extension to the
architectural model of sip, and we shouldn't discount its importance.
The C-Ds of "session" and "early-session" are unusual in that they can
appear in a number of requests and responses. I guess these *could* be
defned as user-context, or method-only-context, or all-messages-context.
(Regardless of which context they are associated with, there need to be
some special rules for how they can be used.)
Note that all of these can be in responses. Yet in the INFO case we
aren't allowing use in responses. So again I think we have a *general*
mechanism that may be used in requests and responses, and potentially
special restrictions that are applied to particular cases.
There is another ugly special case that hasn't been mentioned: multipart
bodies themselves. At least an outermost multipart/mixed needs to be
handled as all-messages-context *by default* for backward compatibility.
That means when it is C-D of "render", since that is the default for it.
I guess a multipart/mixed that has some other C-D need not be treated
that way. E.g. there could be one with C-D of "by-reference", and some
header that references it. But maybe that needs to be forbidden to
ensure some existing app doesn't misinterpret it. But if it were
forbidden, I don't know what someone would do if that is what they need.
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.
This seems right, at least for *outer* body parts. Once you get inside a
multipart whose handling has already been determined by a C-D at that
outer level, I'm not certain what to do with C-Ds that appear on the
contained parts.
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.
This seems to be building on Christer's proposal. Up to a point I think
its probably ok. I was thinking that we didn't need to go this far, but
maybe we do.
The notion of C-D is not unique to SIP, so there are C-D types out there
that say nothing about their relationship to SIP. And of course there
are C-Ds that we will define as being associated with the method-only or
all-messages contexts.
So, I think a new C-D could be defined for use with a particular
package. But to do so it would, I think, require an RFC. (Whatever the
rules are for new C-D types.) Since we aren't going to require an RFC
for info-packages, an info-package that needs a new C-D would still need
an RFC. I also think an info-package could potentially specify that a
particular (existing) C-D be associated with its user-context - as long
as that C-D isn't associated with a message- or all-messages- context.
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.
I agree with this, for the most part.
IMO the key is that when a body part is referenced from a header, the
*reference* defines one sort of processing for the body part. Generally
speaking you don't want any *other* processing to happen to it based
simply on its presence. The by-reference C-D is, IMO, really just a
context that has no *implicit* processing based on its presence.
*In principle* there could be a body part that is referenced more than
once, in which case it would be processed once for each reference.
Similarly, there could be a body part that is present and intended to be
processed based on its context, and there is *also* a reference to it
that should be processed based on the reference. This is not a likely
case by any means, but I think it is cleaner to separate the two
mechanisms. Using the same body for both then just falls out. An
(unlikely and generally nonsensical) example might be a PUBLISH request
containing a presence body, that also has a Geoloc header referring to
the same body part.
To summarize my point: the C-D of a body part provides a way to identify
a context that in turn defines some processing to be performed on that
part. A cid-reference to a body part *also* provides a way to define
some processing to be performed on a part. Either, both, or neither may
apply to any given body part. (The *neither* is important, because there
may be a reference in an optional header that isn't processed by the
recipient.)
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.
I agree it sounds harsh. IMO it is *too* harsh. That may mean I can't
include an application/sdp in a MESSAGE, or in an info-package, even if
it carefully *doesn't* use C-D of "session".
I think we should assume that complying UAs *should* be using C-D
already to disambiguate, and they are simply broken if they don't.
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.
This is a poster child for the problem. AFAIK "application/pidf+xml" is
appropriate for its use, and forcing it to define a new C-T for the same
thing in order to get around this would be a pain. At least in this case
the possibility of conflict with non-conforming implementations isn't
great because Geoloc isn't likely to be needed in PUBLISH or NOTIFY
where conflicts might be possible.
But Geoloc should use "by-reference" when it doesn't want the body
processed other than as a result of the header reference.
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.
I agree we should further discuss the backward compatibility issues. But
I think we need not / should not be quite so resrictive.
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)
I agree with this.
Thanks,
Paul
_______________________________________________
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
