RE: [Sip] Comments on draft-elwell-sip-state-update-02

["Elwell, John" <john.elwell at siemens.com>]

Paul,

By "call" I guess you mean "INVITE-initiated dialog". I am not sure that a
distinction needs to be made between state information associated with any
dialog and state information associated only with an INVITE-initiated
dialog. As far as the proposed modifications to RFC3261 are concerned,
RFC3261 deals only with INVITE-initiated dialogs, so the distinction is
unnecessary. I believe the same is also true of RFC3311.

There may be one or two items that could be considered just message
attributes rather than state, but I believe it is still valid to include
these in a re-INVITE or UPDATE request. Is this just a matter of wording, or
do you believe they should not be included?

John Elwell (john.elwell at ietf.org)


> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of Paul Kyzivat
> Sent: 01 August 2004 20:10
> To: sip at ietf.org
> Subject: [Sip] Comments on draft-elwell-sip-state-update-02
> 
> 
> One issue that is very fuzzy in this draft is the distinction between 
> what is *dialog* state, and what is *call* state. My point is that 
> dialog state is common, and possibly shared, among invitations, 
> subscriptions, refers, and any other use of dialogs that may 
> come along 
> in the future. Call state is state that is specific to an invitation.
> 
> The things mentioned in this draft are a combination of the two:
> - Call-Info header
> - Alert-Info header (early dialogs only)
> - Contact header (change of feature tags)
> - Reply-To header
> - Subject header.
> - P-Asserted-Identity header
> - Privacy header
> - Authenticated Identity Body (AIB)
> - Bodies with Content-Disposition "icon" or "alert"
> - Allowed header
> - Supported header
> - Required header
> 
> If we are to clarify this, we need to clarify that there are 
> two state 
> models and augment them appropriately.
> 
> For each of these it is debatable whether they are truly state, or 
> simply an attribute of the message that carries them.
> 
> Call-Info, Reply-To, Subject: unclear to me. Could be viewed 
> as simply 
> an attribute of the message, or it could truly be call state.
> 
> Alert-Info: seems more like at attribute of a message - 180 or 183 - 
> than as dialog state, even of an early dialog.
> 
> Contact: clearly dialog state. No open questions here that I know of.
> 
> P-A-I, Privacy, AIB: IMO these are indeed dialog state.
> 
> Allowed, Supported, Required: IMO these should be considered 
> as dialog 
> state.
> 
> For those that are deemed stateful, it must made clear 
> whether they must 
> be refreshed at every opportunity or if they remain until explicitly 
> overridden. IMO this is currently an ambiguity in the case of 
> Allowed, 
> Supported, Required. To work right in a stateful model, since 
> there is 
> no way to explictly negate one, I think they must be 
> refreshed in every 
> message. So every message in a dialog would have to provide 
> the full set 
> of supported options.
> 
> 	Paul
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
> 

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