Subject: [Sipping] Very rough notes, Tuesday SIPPING meeting

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Jul 2002 01:01:30 -0500

Here are my very rough notes on today's meeting. If you see issues,
please send text.

--
Dean
----------------------------

Notes, SIPPING Working Group, IETF 54, Session 1

Agenda discussed -- no issues

SIP-T, Jon Peterson

  Slides presented include status review. SIP-T framework is
  essentially complete and currently in IETF LC. Tom Taylor reports
  that SG11 is working in this area and has sent some correspondence
  to IETF on the topic, and is hoping to finalize their work by
  November. Question for scheduling: since there is a dependency on
  tel URL work, when do we need the tel URL done? Jon Peterson reports
  that IESG has said that reference to tel may be informational rather
  than normative.

Status of Working Group Drafts, Rohan Mahy

  Three documents off to RFC editor -- NAI Req, SIP-T, and Hearing
  Impaired requirements. We have been in working group last call on
  call-flows for a long time and hope to conclude with next rev after
  this meeting. Question: None of the emergency stuff (SOS, 911, etc.)
  seems to be on the agenda as WG efforts. Is this intentional?
  Rohan's answer: The IESG has indicated that this needs to go thru
  ieprep. We have a joing meeting of 30 minutes for this
  later. Allikson Mankin confirmed this position.

Service Flows Open Issues, Alan Johnston

  Recent adds include several three-party scenarios. Open issues
  include use of SIP events, join/fork, and discovery of conference
  URI. There also needs to be more attention on the single-line
  extension flow and use of conference package.

Conferencing Open Issues, Rohan Mahy

  Design team met earlier this week. Slides present work plan for
  further effort, including need for set of consistent docs, migrating
  certain requirements to other groups such as MMUSIC, and isolating
  those requirements which should not be met using SIP. Scope proposal
  is to focus on tightly-coupled conferences controlled by a "focus"
  with a one-to-one correspondence with each "member". Must evaluate
  use of SIP vs. alternatives in these roles? Audience polled for
  reasonableness of scope, high level of agreement indicated. Proposed
  conference work plan documented in slides discussed, goal to deliver
  individual documents in September time frame. Question: How is this
  going to be aligned with the SIMPLE work and requirements for what
  needs to be done there? Ans. The policy-setting aspects of handling
  memberships to lists and subscriptions etc. is very similar to the
  membership properties of a conference. Identifying common
  requirements and possible generic solutions is a primary task of
  SIPPING, and we think this will come together as the work proceeds.

Assorted Draft Issues, Jonathan Rosenberg

  Conferencing Event Package: Open questions of scope and whether this
    should be subdivided into multiple event packages.

  Dialog Events Package: Recent changes defined a dialog FSM, has been
    moving toward XML schemas rather than DTDs. Defined "abstract
    dialog" for aggregated state monitoring of generic states like
    "busy". Several elements changed, and IANA registration work
    added. Open question: SUBSCRIBE now applies to all authorized
    dialogs, is it appropriate to do a version targeted to a specific
    dialog? Question: Does the IETF really recommend using schema or
    dtd in IETF?  General understanding seems to be that schema is
    preferred. Comment: There seem to have been some scenarios where
    single-call information was useful. COmment: The W3C has moved to
    discouraging use of DTDs.

  Registration Events Package: Original requirement was to support
    network initiated reregistration. This was generalized to provide
    information about the state of registrations. The draft now
    includes an FSM model of registration state. There has been
    discussion of the relationship between this draft and presence
    events. Author's view is that presence state may include a
    compositing of registration state with other information under
    control of a composition policy. Poll to adopt as a SIPPING
    working group item generally agreed. Comments in opposition from
    Sean Olson: This is a real world application, but should not be a
    SIP working group item -- at best, it is a P-informational sort of
    thing. Counter-position from JDR: Needs to be possible to
    distinguish registration from presence. Sean: The idea of
    standardizing interface between registrar and presence
    server. Counter from Georg Mayer: Since registrar's and presence
    servers may come from different sources, this DOES Noeed to be
    standardized. Question: If we're adopting this, when do we expect
    to finish this? Is it ready for WGLC? There don't appear to be
    technical issues, but further review is called for.

Message Waiting Events Package, Rohan Mahy

  Dates back to Pittsburgh meeting. Three open issues. 

  1) Should the media types concept be replaced with message contexts?
     If you receive an MP3, is that a voice mail, an email, or an
     external reference or what? Comment: the context draft is now in
     the RFCED queue. Discussion: Message context draft addresses many
     issues of presenting sender's intent. It's mature and easy to
     work toward. Comment: This is a definite improvement, raising
     question of "how is this contect list extensible, what's the
     process?"  Answer: There's an IANA registration process
     documented in the context draft. Comment: this would also shorten
     the MWI draft and make it more crisp. Question: Should we add
     instant message to this package as a new context class using IANA
     process in context draft?  Ans. Sounds good so far, will discuss
     on list. Poll: Who likes idea of using message context instead of
     static media lists, result generally favorable (one objection
     noted, not loud).

  2) Should the syntax follow SIP instead of current restrictive
     syntax, including line folding etc.? No objections raised.

  3) If forking or state agents are supported, how do the responses
     get aggregated, and how is specific messaging account targeted?
     This has backward compatibility issues. No objections raised.

  Comment: There are probably scenarios where subscribe/notify is
  wrong metaphor as there is a lot of overhead in maintaining the
  subscription state. Is it reasonable to use otehr mechanisms?
  Ans. Maybe . . . for example, SMS might work.

Content Indirection Requirements, Sean Olson

  Slides discuss current requirements list. Open issues seem
  minimal. Question: When you send this to the far end, you don't know
  that it will be able to support the type of URL refernced. How do
  you know that the reference was acceptable? Suggestion: Use scheme
  parameter from caller preferences.  Counter: This is not a routing
  problem, it's more of an acknowledgement problem, so caller pref is
  probably not right. Perhaps we should have a baseline URI mechanism?
  We probably also need a way to report a refusal of
  indirection. Comment: this work needs to move forward
  rapidly. Comment: is there a requirement to not send an indirection
  unless there is knowledge that that receiver supports the scheme, or
  is it adequate to decline an offered indirection?

Request History Requirements, Mary Barnes

  Several requirments added in -02 rev, primarily relating to
  integrity and privacy protection. Question: is this sufficiently
  cooked to make it a working group item? Response: The concerns that
  remain focus on whether implementation of this stuff becomes
  required in order to interwork public services. For example, is a
  voice mail server built this way going to require people to "fake"
  history entries in order to interact with it? This may raise the
  need for a requirement that services that uses this mechanism be
  abloe to operate in its absence? Poll for adopting as a working
  group item strongly favorable, with only one vocal dissenter. 

Configuration and Profile Delivery Requirements, Dan Petrie

  Slides presented discuss methodology of investigation and analysis
  of several potential configuration delievery protocols. Conclusion
  seems to be that SIP is best mechanism for enrollment and
  notification and that HTTP provides best mechanism for delivery and
  XML provides best container for information. Question: Do we we wish
  to make this a working group item? Response generally favorable,
  with two or three opposed.

Connection Reuse, Rohan Mahy

  Slides review ephemeral connection behavior and
  implications. Discussion requested clarification of some
  points. Questions polled on readership, comprehrension, and belief
  as to utility with generally favorable response. Question: Do we
  need more requirements to be able to do this? Comment: We need to
  analyze security implications carefully. Discussion on splitting
  drafts into reqirements, motiviations, and implementation, generally
  opposed.  Poll on adopting as WG item, generally favorable, few
  dissenters. 

SIP AAA Requirements Open Issues, John Loughney

  Slides discuss assumptions an background. Comment: This seems to be
  focused on fairly traditional provider roles. We may need to
  consider different roles that occur in SIP. Comment: Thought basic
  idea was to put principal database somewhere else, so that nodes
  could run a protocol back to the database and say "Is this okay"? So
  what's the rest of this stuff? Comment: This is a start. It is not
  exhaustive, it doesn't go into a whole lot of things like
  settlement, but needs to be done. Comment: Settlement is outside of
  AAA. Comment: IETF should not get involved in charging and
  billing. Response: The "accounting" here is about
  recordkeeping. Question: Do we have to do all this before anybody
  works on RADIUS or DIAMETER or AKA or whatever behind a SIP server?
  Ans. No, that work will proceed seperately. Comment: many
  requirements are in the form of "A SIP server should", almost like
  host requirements. This becomes a description of the sort of
  additional functions that need to be built into a SIP server for
  deployment in a real network. Comments: This is a major overloading
  of the term AAA, and unless we really are talking "RADIUS on
  steroids" we should be expressing it differently. Proposal: Rohan
  mumbled something about three different scopes and asked people to
  hum, then declared rough consensus on scope two and maybe doing
  scope 1 later or as a strict subset of scope 2 or that a solution
  for the space of scope 1 could be defined in the conext of scope 2.

_______________________________________________
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