Session 1 notes, SIPPING, IETF 58

Status of Work
        Overlap is RFC3578
	Lots of other drafts in WGLC & IESGLC
	Milestone reset is coming (details Thursday)
	Decide what to do with MSCML - no opinions, proceed as individual informational
	Q.SIG - no comments at WGLC, directed review comments have been incorporated
		there are some security related concerns remaining, Rohan to propose
		text.
jp - lots of drafts don't reference identity solutions, a "blank check" would be fine
	Text Chat - manyfolks-sipping-tiop-00, please read
	sIP/RADIUS discussion in RADEXT

Application Interaction
        Jonathan Rosenberg  draft-ietf-sipping-app-interaction-framework-00.txt
	Big rewrite, big issue, how to deliver DTMF
	Two UI types - presentation capable and presentation free
	Two mechanisms, REFER with REFER-TO containing HTTP uri to get script
	SUBSCRIBE to UA, SUBSCRIBE body has KPML, NOTIFY with "digits"
	Don't need App-Info
	GRUU needed in both cases
	Don't need special authentication, can use normal SIP means
	App sessions terminate with dialog
	Solves (one big) forking problem
	If consensus, will need one more cleanup rev, but otherwise done
cj - names are weird, just say there are two mechanisms
jr - need guidance on when to use one over the other
ol - also agree no black/white line
jr - SuBSCRIBE/NOTIFY won't work for HTTP
eb - names are an artifact of when the next thing happens.
jr - will work on the language
rm - orit doesn't want to prohibit fetching of scripts in some other way
	and still use KPML.  Just use 'SHOULD'
ol - example UA doing remote control of an app
jr - that is pretty far off the scope, for example security mechanisms assume
	all entities are on the call path
rm - could get GRUU from dialog package, and thus not on the call path
jr - concerned about interoperability
jp - what kind of exclusivity does the framework provide? Don't need so much
	exclusion of use
Chair - hum for two mechanisms with recommendations on how to use 
        result: strong consensus

Event Package for DTMF Signals
          Joe Zebarth  draft-zebarth-sipping-dtmfad-00.txt
   Needed something for DTMF to implement prepaid calling card soon.  Want an Event Package.
   Need an RFC to register it, thus this work.
   Sees this as complementary to KPML, because it moves the processing intensity from 
	the Notifier (KPML) to app server (dtmfad)
   Want an Informational to get the IANA registration of the package
eb - more than processing difference, it's different in how low level events are
	handled (eg multiple events per digit)
chair - two issues, are there technical issues with the draft, and is this good
	for sip
rs  - issue is whether this is a good idea, then deal with the technical issues
cj - processing difference is a drop in the bucket
jr - completely overlaps with standards track documents, and thus needs to show
	there are technical problems with the standards track work to be progressed
	Also, we have resolved KPML issues, so timing isn't a factor any more
am - could we have a liason from T1 specifying time frame requirements
kd - this is an individual submission, there is a process, only issue is does this
	fit the process
br - appeal to T1 to work with us to get one solution, but if they want it,
	 lots of examples in IETF of work duplicating standards track


0935 Key Press Stimulus Protocol
          Eric Burger
          draft-ietf-sipping-kpml-01.txt
     remove href, added MSCML tag attribute
     Addressing Stream of Interest - SUBSCRIBE on dialog is, harder for 3rd parties
     Issues
       is SUB/NOT the right model?  Speak Now! 
       Is SDP addressing okay?
       3 ways to specify digit map, all required
cj - 3 ways is too many
rm - not okay to require support for 3 mechanisms
?? - can we have names for styles, with ACCEPT...
  take to list
jd - 3rd parties are hard, security issues..., changes framework
eb - Immediate Notify, with empty body, everyone okay?  no objection


Conferencing Design Team Report
          Alan Johnson draft-ietf-sipping-conference-package-02.txt
                       draft-ietf-sipping-cc-conferencing-02.txt
     One more rev for consistancy, then WGLC.  Will need alignment with GRUU
     Changes to conf package
	Remove pkg parms
        remove ptrs to xcon stuff
        remove dialog info
        align media stream info with SDP, including SSRC
	Status enhanced with activity and history
	Added sidebar roster (one level)
     There will be a sidebar draft, but probably an xcon document
jr - how does sidebar interact with framework doc
aj - need lots of detail, will summarize for framework

Transcoding Design Team
          Gonzalo Camarillo
          draft-camarillo-sipping-transc-3pcc-00.txt
          draft-camarillo-sipping-transc-framework-00.txt 
          draft-camarillo-sipping-transc-b2bua-00.txt
          draft-camarillo-mmusic-source-sink-01.txt

         Two models, 3pcc model and conference bridge model
         Framework and 3pcc model ready to make WG items, still working
		on conference bridge model
chair - humm for adding milestones for this work including conf bridge model
	result: strong consensus
chair - humm adopt framework doc as WG item
	result: strong consensus
chair - humm adopt 3pcc doc as WG item
	result: strong consensus
kd - clarify that conference bridge model is agreed part of adopted work
chairs - yes, will be a milestone, just that the design team document is not yet
	ready to be adopted as a WG item

Emergency Calls Design Team
       Tom Taylor
       Henning has some drafts on requirements and marking emergency calls
       Taylor has draft on terminating sip emergency call in existing systems
       Issues
	  Identifying calls - probably sos@localdomain
	      must distinguish between regular and hearing impaired ECCs
	  Routing - depends on caller location
          Presenting location to the ECC
		current system uses calling party number to determine location
		PSTN may determine calling party number based on incoming circuit
	Presenting callback number
	Preventing nuisance calls

	Solutions depend on applications scenario

	Where to go from here
		How to carry loc info in SIP
jp - other forms of intermediaries could influence it
rm - motivate why intermediares need to insert location
tt - Scenarios described in the draft where this comes from
hs - two examples - phones without emergency support, and phones not
	recognizing emergency call.
     routing is harder, b2bua....
     if you are making proposals, handle all the problems
	identify the call as emergency
	get location
	route to psap based on location
jp - emergency calls could be handled by something very special, who cares
	what you call it
hs - want to use existing sip, not something special
br - NENA has two wg working on this, will input requirements into SIPPING
	for protocol work
rm - NENA is North America, but is soliciting input from others
?? - Don't forget hearing impaired users

 
Event Package for User Configuration Profiles
          Dan Petrie  draft-ietf-sipping-config-framework-01.txt

     Compare this to simple XCAP
     Goal is to be independent of delivery protocol
	Token represents the profile (uri in xcap)
	Multiple profiles may be associated with the token
	Profiles and deltas provided via content indirection
jr - can't we get these more aligned?  Does the target include wireless?
an - should be separate packages
chair - who else has an opinion?
jr - maybe a conference call to resolve
an - is xcap the universal answer?  There are other protocols
dp - goal was to be protocol agnostic
ol - no problem with 2 packages, problem with xcap.  Need to
    standardize the schema.  Shouldn't limit to xcap schema.
ms - wireless has lots of devices, don't want sip only mechanisms

   security AES encrypt profile ?MUST?
   MAY use basic/digest authentication over https
   MAY use client cert
rm - okay to MUST on HTTP authentication, also need something for
    insecure protocols
am - need a MUST IMPLEMENT
chair - have conf call, take to list

Intermediary Session Policies in SIP
          Volker Hilt
          draft-ietf-sipping-session-policy-req-00.txt
          draft-hilt-sipping-session-indep-policy-00.txt
          draft-hilt-sipping-session-spec-policy-00.txt
<sorry, fell behind>
	Session Dependent Issues
		Should we use preconditions
		Subsequent offer/answer
		Two party consent vs one part consent
			requires 3 pass policy exchange
gc - don't need discovery - one party is ok
jr - two pass model is okay
rm - don't like reinventing SDP in headers, need a reasonable way for proxy
  to modify SDP
jr - don't agree we have reinvented SDP
chair - humm for send docs to sip
	result: stong negative

Reason Header for Preemption
          James Polk
          draft-polk-sipping-reason-header-for-preemption-00.txt
Progress as individual draft


Location Conveyance Requirements
          Brian Rosen
          draft-polk-sipping-location-requirements-01.txt
	Changes - body, not header
		New emergency rqts
	Issues
		self signed certs
		how to import geopriv security wording and meet rqmts
			probably okay with S/MIME must implement,
			TLS/IPSEC hop by hop for some scenarios
chair - humm for milestone 
  result: strong consensus
        humm for adopt this doc as start point
  result: strong consensus
kd - need to look at requirements, revisit header vs body
jp - 3261 doesn't prohibit proxies from looking at bodies
   yes, means multipart will become a must


Transfer Issues
          Dan Petrie
          draft-petrie-sipping-xfer-issues-00.txt
aj - good issues, want to