Subject: [Sipping] I-D draft-petrie-sipping-profile-datasets-01.txt

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 01 Mar 2005 16:27:08 -0500

This draft has not yet made it through the
works due to a mistake on my part.  I wanted
to get this out in the mean time.

Title:
A Schema and Guidelines for Defining Session
Initiation Protocol User Agent Profile Data Sets

Abstract:
This document defines the requirements and a format for SIP user 
agent profile data. An overall schema is specified for the 
definition of profile data sets. The schema also provides for 
expressing constraints for how multiple sources of profile data 
are to be combined. This document provides a guide to 
considerations, policies and syntax for defining data sets to be 
included in profile data. It also explores some specific data 
sets to test the requirements, assumptions and syntax.

Html:
http://scm.sipfoundry.org/viewsvn/*checkout*/ietf-drafts/petrie/profile-data-sets/draft-petrie-sipping-profile-datasets-01.html?rev=436

Text:
http://scm.sipfoundry.org/rep/ietf-drafts/petrie/profile-data-sets/draft-petrie-sipping-profile-datasets-01.txt

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christian Stredicke" <[email-masked]>
Date: Tue, 8 Mar 2005 11:36:17 +0100

Hi, I think this is important work. If we can solve this problem, we
will make life for the ITSP much easier. 

I have a few comments:

Chapter 3.1.3: I think this is a bad use case. The transport layer
preference can be controlled via the existance on DNS SRV entries for
the domain. In general, I think we should use DNS entries whenever it
makes sense. For example, for locating the STUN server look up
_stun._udp.domain.com.

Chapter 3.2.6: Well, its really a little bit hard to understand, at
least for me. I hope that it is pretty simple to implement. Especially
the merging raises many questions to me. Of course, if you download a
setting from your operator and then decide to change it, what do you
do?! If that was an address book entry, well then you would probably
want to upload it again. My proposal would be to define the setting
download procedure as pure one-way street and if there is something in
the way, it gets overwritten. Or would you expect that a analog PSTN
user can change its telephone number? What if an address book entry
comes from two places? My suggestion would be to avoid the whole merging
discussion and just say "dont do it".

Chapter 6.7: I would take Address Book out of the discussion, this
discussion will be endless...

General comment:

Defining the profile datasets does not completely solve the problem. I
think we need to work on specific settings that should be available in
the different environments. I mean in DHCP people are not only talking
about a generic way to transport settings, they actually specify down to
the bits how the message should look like. I think we should start this
in SIP as well (maybe in a seperate document and a seperate discussion).
Then we can take the examples out of the document and make them real.

Maybe we can start on the concrete settings for the ITSP. Probably many
ITSP would like to state their requirements.

Also a concrete example for this ITSP case where a subscriber receives a
SIP URI would be extremly helpful. Something like a manually assembled
Ethereal file!

Christian

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daniel G. Petrie
> Sent: Tuesday, March 01, 2005 10:46 PM
> To: [email-masked]
> Subject: [Sipping] I-D draft-petrie-sipping-profile-datasets-01.txt
> 
> This draft has not yet made it through the works due to a 
> mistake on my part.  I wanted to get this out in the mean time.
> 
> Title:
> A Schema and Guidelines for Defining Session Initiation 
> Protocol User Agent Profile Data Sets
> 
> Abstract:
> This document defines the requirements and a format for SIP 
> user agent profile data. An overall schema is specified for 
> the definition of profile data sets. The schema also provides 
> for expressing constraints for how multiple sources of 
> profile data are to be combined. This document provides a 
> guide to considerations, policies and syntax for defining 
> data sets to be included in profile data. It also explores 
> some specific data sets to test the requirements, assumptions 
> and syntax.
> 
> Html:
> http://scm.sipfoundry.org/viewsvn/*checkout*/ietf-drafts/petri
> e/profile-data-sets/draft-petrie-sipping-profile-datasets-01.h
> tml?rev=436
> 
> Text:
> http://scm.sipfoundry.org/rep/ietf-drafts/petrie/profile-data-
> sets/draft-petrie-sipping-profile-datasets-01.txt
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
>

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 8 Mar 2005 06:08:56 -0800 (PST)

Christian:
Thank you for your comments.  My responses
are inline below.

Cheers,
Dan

--- Christian Stredicke <[email-masked]>
> makes sense. For example, for locating the STUN
The intension here is not to substitute or replace
DNS.  There are deployments and user preference
reasons to constrain the transport protocols
indicated by DNS.

> discussion and just say "dont do it".

Certainly there there are properties that may not
need the ability to change (as you point out an AOR).
However there are properties that are important to
provide the ablity to overwrite or aggregate across
the profile types.  Though a user may not want to
change their AOR, they are very likely to change
properties related to that AOR (e.g. call handling
properties).  Certainly an enterprise is likely
to specify a set of speed dial numbers for use
within their business and users are likely to
create their own speed dial numbers as well.

This is an example where aggregation is the
correct algorithm for merging of the property.
There is a simple why to handle collisions in
this case (e.g. enterprise and user specify different
AOR for same speed dial number in device and user
profiles respectively).   By default the users 
speed dial preference wins.  However the enterprise
needs the ability to specify that a property may
not be overwritten by the user.  Should the 
speed dial number with the collision be defined
as having the "policy" attribute value of "mandatory".
The user would not be able to set the same speed
dial.  The user's property setting the same speed
dial would be ignored.

> discussion will be endless...
Yes I agree that will be difficult to come to
concensus on.  I think the way to make progress
on the properties is to pick the simpler, important
properties that are clearly common to user agent
and necessary for basic functionality.  Each of
these could be defined in a small, separate
draft:

  + SIP timers, ports and transport protocols
  + Media types and codec preferences
  + NAT traversal info.
  + AORs and credentials

> > Subject: [Sipping] I-D
> draft-petrie-sipping-profile-datasets-01.txt
> > 
> > Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Christian Stredicke" <[email-masked]>
Date: Wed, 16 Mar 2005 10:17:31 +0100

My primary concern is that we keep the configuration as simple as
possible. If you look at the market today, people are using extremly
pragmatic approaches that cost them maybe a kilobyte of object code. My
preference would be simplicity and then a big feature set. 

Simlicity of course in scope of what you need to have a SIP phone
anyway. That means that we can expect XML, HTTP and SIP at no extra
cost. 

Of course, the first priority it to have a standard at all!

CS

> From: Daniel G. Petrie [mailto:[email-masked]] 
> Sent: Tuesday, March 08, 2005 3:16 PM
> To: Christian Stredicke; Daniel G. Petrie
> Cc: [email-masked]
> Subject: RE: [Sipping] I-D 
> Thank you for your comments.  My responses are inline below.
> 
> Cheers,
> Dan
> 
> The intension here is not to substitute or replace DNS.  
> There are deployments and user preference reasons to 
> constrain the transport protocols indicated by DNS.
> 
> > comes from two places? My suggestion would be to avoid the whole 
> > merging discussion and just say "dont do it".
> > 
> 
> Certainly there there are properties that may not need the 
> ability to change (as you point out an AOR).
> However there are properties that are important to provide 
> the ablity to overwrite or aggregate across the profile 
> types.  Though a user may not want to change their AOR, they 
> are very likely to change properties related to that AOR 
> (e.g. call handling properties).  Certainly an enterprise is 
> likely to specify a set of speed dial numbers for use within 
> their business and users are likely to create their own speed 
> dial numbers as well.
> 
> This is an example where aggregation is the correct algorithm 
> for merging of the property.
> There is a simple why to handle collisions in this case (e.g. 
> enterprise and user specify different AOR for same speed dial 
> number in device and user
> speed dial preference wins.  However the enterprise needs the 
> ability to specify that a property may not be overwritten by 
> the user.  Should the speed dial number with the collision be 
> defined as having the "policy" attribute value of "mandatory".
> The user would not be able to set the same speed dial.  The 
> user's property setting the same speed dial would be ignored.
> 
>