Subject: [Simple] Re: Communication means in draft-ietf-impp-cpim-pidf-05

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Sep 2002 10:56:35 -0400

Moving discussion to the simple list...

Jonathan Rosenberg wrote:
> 
> I agree that, in the case of
> SIP (although it really is more general), having extension attributes
> that convey the information gleaned from things like caller preferences
> (media types supported, for example) is a worthwhile goal. Indeed, such
> an item is ALREADY on the charter of SIMPLE, and appears to be due this
> month....

Hmm - is it:

  Goals and Milestones:
  ...
  SEP 02  Submission of SIMPLE PIDF profile to IESG for 
          publication as Proposed Standard 

that you are referring to? Its good if the SIMPLE charter already covers this work. But as far as I know there hasn't yet been any work on this has there?

Considering the amount of heat this subject has generated on the impp list, do we need to first develop a set of requirements for PIDF extensions in SIMPLE?

My feeling is that a good start (and maybe finish) would be to reflect the callee capabilities, as defined in callerprefs, in PIDF. It has been discussed ad nauseum on impp why at least media capabilities are important. I don't know if we need to repeat that discussion here, or if we need to do it for each pref type in callerprefs. One advantage to agreeing on callerprefs is that maybe we can make a decision on the whole thing rather than considering each piece separately.

	Paul

	Paul
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Adrian Bateman" <[email-masked]>
Date: Thu, 5 Sep 2002 16:42:03 +0100

On 05 September 2002 15:56, Paul Kyzivat wrote:
> > that convey the information gleaned from things like caller 
> > preferences (media types supported, for example) is a worthwhile
goal. 
> > Indeed, such an item is ALREADY on the charter of SIMPLE, and
appears 
> > to be due this month....
> that you are referring to? Its good if the SIMPLE charter already 
> covers this work. But as far as I know there hasn't yet been any work 
> on this has there?
> 
> Considering the amount of heat this subject has generated on the impp 
> list, do we need to first develop a set of requirements for PIDF 
> extensions in SIMPLE?

I seem to remember it having been discussed at length without conclusion
here too, but for different reasons. In the past (and as result of
passing on it for now in IMPP), there has been a desire to have a set of
'IM' status values beyond OPEN and CLOSED for things that people have
been used to such as away, busy, etc.

To my mind, the debate in the past always degenerated into a general
discussion where people either tried to argue about the openness or
closedness of particular states or they expanded the scope to start
talking about SIP media types too. 'Degenerated' may be a bit harsh
since some of those arguments are valid but didn't, I think, contribute
to the particular discussion at hand: IM status values. I've tried to
move that discussion along in the past by trying to talk about why IM
status values are important and what purpose they will serve so now
might be a good time to try to raise that again.

For interop, PIDF says that for status value ranges that extend <basic>
(i.e. they imply some OPEN or CLOSED value), the <basic> value must also
be present. My suggestion for IM status values is to have a dictionary
of values without necessitating an inherent OPEN/CLOSED property to
avoid endless debate. As far as possible, values with the same semantics
should be reduced to one word (e.g. if there is a consensus that 'away'
and 'idle' are the same, then we only need one). But if there are
objections, I see no major disadvantage with having a larger dictionary
within reason (e.g. if there is no consensus that 'dnd' and 'busy' are
the same, say, then they could both be included and some people will
interpret them as the same and others as different).

My reasoning for this is as follows. I believe that:
* People will largely use the values for presentational purposes. 
* It is unlikely that there will be consensus about precise semantics
for certain values and so people building automata to interpret the
values will have to use some local policy logic anyway.
* The ultimate fallback is the OPEN/CLOSED <basic> value that MUST be
present.

> My feeling is that a good start (and maybe finish) would be to reflect

> the callee capabilities, as defined in callerprefs, in PIDF. It has 
> been discussed ad nauseum on impp why at least media capabilities are 
> important. I don't know if we need to repeat that discussion here, or 
> if we need to do it for each pref type in callerprefs. One advantage 
> to agreeing on callerprefs is that maybe we can make a decision on the

> whole thing rather than considering each piece separately.

I'm afraid I don't know enough to contribute meaningfully to the
discussion regarding capabilities. However, I think these two cases can
be done in parallel, and I hope that part of this work may help towards
the documentation we'd like in IMPP for defining an extension to PIDF.

Adrian.