Re: [Sip] Body handling - Contexts WAS (Re: multiple bodies in any SIP message)

[Eric Burger]

So I went with C-D for the last round of INFO. This isn't e-mail, so matching the C-D with the method, on a per-method basis, works in all cases, as the C-D is a unique (because of the IANA registry) and the method defines it. Thus no one will use INFO's C-D for something else (unless they want to get slapped silly).

On Jan 8, 2009, at 9:17 AM, Gonzalo Camarillo wrote:

Hi,



Thanks,

Gonzalo

Hadriel Kaplan wrote:

by now, most people should be back from their vacation. I will wait a few days for further comments and, if everybody is happy with the current draft and no one proposes new text, we will go ahead request its publication.

I think that's really a question for the others (Paul, Dean, Eric). I interpreted body-handling to address the issue already, but maybe not the backward compatibility issue. Also, section 8.1. talks about the context being defined by the method, C-D and C-T. It should probably mention that the Event package for SUB/NOT/PUB and soon the Info-Event package narrows the context further. And I'm not sure that C-T has anything to do with defining a context.

-hadriel

-----Original Message-----
From: Gonzalo Camarillo [mailto:gonzalo.camari...@ericsson.com]
Sent: Tuesday, December 16, 2008 4:05 AM
To: Hadriel Kaplan
Cc: Eric Burger; SIP List

SIP message)

Hi Hadriel,


> 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


they take them into account when defining new extensions?

Thanks,

Gonzalo


Hadriel Kaplan wrote:

Subject: Body handling - Contexts WAS (Re: [Sip] multiple bodies in any > I think the body-handling draft already does it, although maybe I'm 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

[note: changing the thread to be consistent]

-----Original Message-----

From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of

Eric

Burger
Sent: Sunday, December 07, 2008 10:37 AM

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.

Everyone seems to think there needs to be a generic way of identifying

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

already used today either. (and that includes changing geoloc's C-T
immediately)

"render" or the other ones already in use, and that they can't use a C-T

: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

the user-context defined by the "dtmf" package in an INFO.

(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

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

need this context to be defined separately.

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

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

class for some methods (INV/UPD/etc.).

derived class from that for a given package, which may just be the same

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

for now.

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

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

Require header, to dissuade people from doing that.

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

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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implement...@cs.columbia.edu for questions on current sip
Use sipp...@ietf.org for new developments on the application of sip