Notes from SIPPING Session 1 IETF 62

Reported by Azita Kia


Sipping  March 10, 2005   Notes

Config framework:  Dan Petrie

XCAP section: 
-    Where do we specify the binding: take offline and discuss with Jonathan
-    Cullen:  security as defined doesn’t work for any other protocol than HTTP, so either correct it or pull it out:   You will need to transport account name and password back into SIP message. If we say that we can use these other protocols then we have to make sure that usage will work. Make it work for HTTP(S) and XCAP and leave the rest out.
-    Rohan feels it should be left in and demonstrated, but given the state of the draft Cullen is suggesting it is too late to demonstrate other protocols
-    Discussion is taken off line.

Profile Data Sets:  Dan Petrie

-    One criticism is that hierarchy may not work in some cases, would be good to hear about use cases where this hierarchy does not work
-    Framework is done, but does not define the content type.  Framework can be used with proprietary content type, question is can the framework proceed without specifying at least a default type. Rohan believes we can proceed without a default type, but there are some disagreements.
-    How do we reconcile the attributes during a merge, some default values in the hierarchy may need to be specified to facilitate a decision
-    Cullen’s comment due to lack of engagement from participants: This is the most important work going on in sipping right now

Session Independent Policies: Volker Hilt

-    Not many people have read the draft.  Chair displayed disappointment in lack of engagement. Complain was raised that there is 4 novels worth of reading in these drafts.  Discussion on WG procedures ensued.
-    Oran: if the XML schema is designed to include only text strings as opposed to data types that match the registry, processing can be inefficient, suggest to consider specific data types that would match registry content, as is done in IM
-    Jonathan: registry imports will not work when we add extentions, so just be careful with specification of names and how fields are defined.
-    Where will these policies be applied? The local network?  Read the draft
-    Cullen:  try to simplify, limit the elements
-    Jonathan:  ditto
-    Dan and Jonathan: There is some confusion between this and the Data elements draft, need to coordinate better to simplify
-    Henning: this looks like the netconf framework in that we are trying to establish config using policy
-    Rohan: this method will try to transform a session through policy negotiation and not do a deterministic config as is done in netconf
-    Jonathan:  We need to look at, what are the semantic operations that we are looking for.
-    Rohan is suggesting to not use content disposition sessions  (???)
-    Jonathan: we need to have a discussion on whether we need session dependent policy or can we solve these problems (what are they?) through session independent policy. Need to come up with use cases. Data is not the use case. We need specific scenarios that may come up during deployment.

Consent based communication: Gonzalo

-    Not clear why you need to keep state since state will be returned in the encrypted uri that is returned.  Issue is how to encode the state, where in the uri. This is the current discussion.
-    Jon: SIP publish should be paired with SIP subscribe
-    Henning: ???
-    Mark:  multiple permissions. Can they be aggregated?
-    Rohan: advocates a hybrid solution where both single and groups of permissions can be queried
-    Jonathan: Does not like the bundled version, because it kills the hierarchy model of users. It assumes a completely flat user space. You also can not do wild-carding
-    Dean: There is no Single repository of consent info for a specific user C, to find all consent info, C will have to go all over and gather the info.  (that seems to be the way the call model works)
-    Rohan:  this works because the primary operation is a WRITE operation as opposed to READ
-    Oran:  Is there a requirement to revoke consent? YES. 
-    Rohan: you don’t need to READ in order to revoke consent. Every request will have the permissions which can be used later on for revocation. It is like a mailing list where every message contains the info you need to unsubscribe.
-    Paul: ???
-    Jon:  ???  There has to be a method for users to take part in this feature without getting prompted for consent info.
-    Mark: ???
-    Hisham: ???
-    Jonathan:  ???

The last several comments were around use of similar techniques as email applications for consent, whether this is useful or not, etc. Sorry could not capture all details.

Transcoding Framework: Gonzalo
Sorry, no notes on this ☹

V6 transition:
Document accepted

Functionality  of Existing SBCs
-    Gonzalo: Clarification on scope, few scattered comments nothing compelling.
-    Decided to merge both drafts, and introduce this new draft and submit to the WG for further work.

More discussions on consent framework:
-    Jonathan: Even XML is out of scope because we don’t have xml in sip. If xml does not exist, if we standardize the content we can use xcap to apply the same function.
-    Rohan:  use this implementation for a dumb UA, in such cases we can use an HTTP URI for these dumb UA. We have implementable solution today, we can use xcap when it is implemented.
-    Dumb UAs of today have a lot of HTTP but no SIP, so to claim that the solution exists today is false.
-    Jonathan:  We lack components of implementation such as identity. If we make this mandatory then all vendors will implement it and later we will need more flexibility and we will not have it.
-    Rohan: ???
-   
Vote on: Publish the framework, yes or no. We need something as min baseline mandatory implementation. Humming did not indicate any consensus.