Reported by Vijay Gurbani
Agenda:
Agenda bashing -- agenda accepted.
Published 3 RFCs since IETF 59 -- 3824, 3725, 3680.
3 docs in ed q - msg waiting, early media, and early
session disp.
3 with AD: 3gpp r5 reqs, qsig to SIP, 3pcc transcoding.
Pre-WGLC drafts - cc transfer, torture tests (need volunteers
for this; disappointing take up on the mailing list call).
transcoding framework (gonzalo will find cycles to finish
it). sos draft is waiting feedback from URI mailing list;
waiting for feedback outside the WG.
cc framework, reason header for premption - waiting for
RP.
Allison: Ted has concerns regarding sos draft based on his
early review.
Ted's concerns are encapuslated in a draft and are not
being discussed in any wg.
New milestones - jul '04: KPML. Need to close open issues
this week and wglc next. Aug '04: Conf. reqs and cc conf -- Alan
will take the lead on this. Location reqs has been merged
with location solutions and will be 1 document.
...
Dec '04: event filtering, caller prefs usecases, svc. examples.
Gonzalo: the WG is looking for more editors, current ones
are running out of cycles. Looking for new eds to work with
senior eds so the former can get a brain dump of the latter
on how to write successful drafts. session policies is one of
the first ones tried.
Jan '05: session indep. policies.
...
march '05: either recharter or close down the WG.
--
REFER issues:
draft-olson-sipping-refer-extensions has 2 controversioal
extensins to REF. Nothing has happened with this draft.
Need to move it forward.
Orit: removed all the controversial things; two things
left: adding norefersub and suppress the implicit subs. and
allow Refer-To to contain feature parameters...next step:
become a SIP
Rohan called for any objections on sending this to SIP WG.
No one objected, but Rohan asked the attendees to look it
once over in the next couple of weeks.
App interaction, Jonathan Rosenberg.
Revised app interaction; mostly small cleanups. One major
issue: if I want to refer someone to a web site for a credit
card the refer needs to provide a context for a dialog. For
subs we use event-header parameter; used something similar
for this called "context" and a Require token.
Other changes: added motivational text from KPML; not been
synched up with latest KPML rev.
Had a normative ref. for SIP identity; does not need a
normative ref; infor. suffices.
app needs to understand the capabilities of the device --
what markup it supports -- before interaction. Use of
Reg EVent for this.
Authorizing REF/SUB - cannot be automatic w/o sips.
Softened the wording about the ap being in the dialog
path.
Updated exmaples to use TLS and added needed IANA params.
Next steps: No open issues beyond KPML synchup; ready for WGLC.
Asked for comments/concerns: None raised.
KPML, Martin Dolly.
Received many comments at the Boston interim meeting.
editorial cleanup following those comments. Aligned with
app-interactions.
Added GRUU text in doc; removed concept of "leg",
beefed up security, added 502 to KPML status code.
removed refs to mscml; expanded abstract and many other
changes.
Issue 1: One of the issues was privacy of user input --
one app subs to digits to get the CC number; don't want next app
to get the credit card number.
Options: among 4 options ranging from who cares, do not
quarantine (buffering of digits), matter of local policy,
flush buffer.
Rohan: split this in two separate decisions: can we
get away with who cares or do no buffering? Feedback
from WG has been that we do care about buffering since
we do not want to constantly re-enter digits.
Cullen: do no quarantining (no buffering).
Jonathan: Need to understand use cases where a second
app needs to get access to the digits?
<Discussion ensused regarding use cases for this...the
discussion veered towards KPML being a digit transport
protocol or an app interaction protocol; some of the behavior
being asked of it now reflects the latter. No option chosen;
more discussion on wg list>.
Issue 2: explanatory content between app interaction
and KPML-03. KPML-04 has solved this by keeping all
non-normative text in app-inter and keep all normative
protocol text in KPML.
Jonathan: No open issue here; some of the opening para
from app-inter really belongs to KPML and I have no
problem putting it there.
<Discussion went back to Issue 1; Cullen supports
"do no quarantine" and others support "flushing buffers".
Eric gave an example on why "do no quarantine" will not
work...discussion ensued and Dean summarized the options
as being retaining digits
1: From the beginning of current dialog
2: From last stable transition state
3: From the moment of the SUBS processing forward
Dean asked the participants to hammer out something by
Friday WG meeting).
Dialog package, Rohan Mahy
Hold issue: lots of folks wanted a passive/active flag or
other indicator they could use for hold. Proposed adding
a new callee-caps feature tag for "interactivity". Lots
of controversy. 4 options:
0. remove all hold-related params from document and do
separate docs for these params.
1. have one parameter: "i am paying enough attention to
send a BYE".
2. (a) parameter for don't know how to send BYE, (b) i am
not rendering media from any of the m lines in the current
SDP.
3. 2+(c): A UA paired up with another more active SIP UA.
The 3rd one is a relationship where you want to know
the buddy's name and this goes beyond what we want to
express in caller-caps.
Rohan's proposal: Option 2. Proposed names for the two
params: "byless" used when UA cannot reasonably
determine when to send a BYE or is unable to send a BYE.
Jonathan: how do you determine how this parameter gets
set?
Cullen: We should put words like "it is expected that
this device will not send a BYE".
Jonathan: Prefer a very explicit defnition so that
implementors know what the behavior is.
The second param is called the "rendering" param; default
setting is "unknown". If the value is "no" --> On hold.
Jonathan: again, what does rendering mean? Does a TiVO
box qualify if it is saving data to disc?
Two other open issues: how do you handle the case when
a phone is picked but an INVITE has not been sent out yet.
Also, what is the lifetime of the dialog that is in
terminated state?
Keith: you are trying to invent things that are not part
of the dialog, but are part of the UI. WHich one are
we doing?
Rohan: Currently, the doc describes dialog state.
Jonathan: We specifically decided not to go to UI modeling
back when I was editing the document. These things are
definitely in the UI domain. You are making all kinds of
assumptions of the UI based on perception of a dialog
state.
Cullen: The use cases in the doc for this I-D are around
UI. We could do another package for UI and you subs to
two packages. This doc should meet both UI and dialog
state.
Jonathan: If we are going down this line, we need to
properly consider all possible cases.
<Dean asked the participants to take this offline and
discuss it further.>
Event throttles, Aki Niemi
merged req draft w/ solution draft. incorprated wglc comments.
wglc summary: should client be able to dictate the buffer
policy of the notifier? COnclusion: No. Uneeded complexity
and uneeded behavior.
What buffer policies and packet treatment should we
define? FIFO, LIFO? Conclusion: event pkg. specific and
only two make sense: Last In Out Trash Others for full state
and Merge for partial state.
Cleaned up overview of operations.
Open issues: only one left: REQ7...should we add more
recommendations or is this reasonable enough?
Should we make this a WG item?
Jonathan: It's getting better compared to older revs.
Event packages have always said that event packages must
thorttle NOTs, but does not specify how. The general
problem you are solving is not consuming too much bandwidth
over air interface. The message will still grow linearly
and this solution will not buy you much.
Other problem is: what data is interesting to me as a
watcher. WHat can you throw away without impacting the
information coming to me.
Gonzalo: the reqs to this I-D are already WG item. This
doc has reqs and solution.
Jonathan: This is effectively as an extension to rfc3265.
Since it defines a new mechanism for throttling.
Dean: The WG processed the reqs and a reasonable solution
would require an extension to rfc3265. Should we punt
this over to SIP to deal with there. We will keep it in
sipping until we have clear requirements and we decide
what we are trying to do.
Reqs and framework on consent based communications in SIP.
Reqs: amplification request attack -- one request goes to
multiple destinations. Have we captured all the existing
reqs or is something missing?
Miguel: I want to send a message to be distributed to all
URIs, and if one fails then what happens. Other case is
you want to distribute to as many as possible and if some
fail, no problem.
??: Can we turn off messages from a relay we are not
interested in?
Rohan: The reqs need a lot more motivation and scenarios
around them.
Cullen: Like where this is heading; we need some verbiage
on how long the consents lasts and how assertive are the
identities in the framework (i.e. if From contains sip:A
can I be sure that it is indeed from A).
Open issue: Target URI. Contents of a permission
document does not include a target URI right now.
Should we include it? Proposal: yes, as an optional
element.
Open issue: description of the permissions being requested.
The CONSENT request neds to describe the permissions
being requested. Use a header field, send a
template (e.g. a MESSAGE) using a require header, use an
XML body. Proposal: XML body.
Hisham: We need to restrict the domain of this document.
ARe we exploding a request or specifying that contact me
over video and not audio...
Jonathan: In favor of doing this work and considering the
scope beyond only URI exploder.
Rohan: This is young enough that we should do this one
more time as an individual; but the WG should keep in mind
while reviewing this I-D on if it should become a WG agenda.
Dean: We're going to solve this problem: (a) are the reqs
enough, b: are the solutions adequate to serve as a baseline
going forward.
Jon: we need to delineate the workings of this draft with
normal SIP forking.
Dean: polled on if this series of drafts should be a WG item.
The poll indicated yes.
1735: Meeting adjourned.