Notes on SIP Session 1, IETF 62

Reported by Vijay Gurbani

Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216
SIP Session 1 - Monday, 7:30 PM - 10:00 PM.

Agenda bashed; no changes.  We are not discussing any
drafts not in the IETF draft repository.

Until the slides presented become part of IETF archive,
they can be accessed from:
http://www.softarmor.com/sipwg/meets/ietf62/slides/index.html

RFC 3968 and 69 published since IETF 61.  3 on eq q,
including session-timer (in 48 hours).  Publication
requested on some and others in IESG last stages (sctp,
sip-guidelines, and content-indirect).  WGLC going on
on a bunch (sip-refer-with-norefersub, sip-gruu, ...)

Charter is obsolete on the IETF page; updates sent
twice but not yet hosted.

GRUU, Jonathan Rosenberg

Substantial revision to this doc.  Motivation has been
beefed up, GRUU property of long-liveliness is back;
GRUUs resolved using rfc3263 (like any other SIP URI);
updated UML diagram.

(Went through the UML model; see slides).

Changes to previous doc; contact expiration handling
defined - when contact expires and is not bound to
AoR, so is the GRUU.  Declared out of scope has been
the issue around redundancy -- maybe Cullen's outbound
I-D is the right place for this.  SIPS handling: both
sip and sips versions are created when a GRUU is, and
route to the same resource.  URI scheme of GRUU matches
scheme of To (side: we should better specify sips behavior
in rfc3261 itself). 

(Went through some R-R interaction cases; see slides).
Proxies may have to run user location on the request.
Another scenario included a proxy sending a request
back to the upstream entity after resolution -- not
optimized.  There are ways around this and some discussion
ensued at the mic, none of which reached a conclusion.

Open issue 1: Find AoR from GRUU.  Long debate on the
list about this since GRUUs may not be correlate-able for
billing and call logs.  A few proposals appeared on the
list, but the current compromise appears to be: keep
current mechanism, but define a naming convention for
GRUU that has AoR and instance ID visible.

Adam: From simple's point of view, why can't you use
the URI in the document?  Why depend on the GRUU?
Henning: One reason is that a relationship element
may have my secretary's GRUU that I would want to contact
later; if that is a GRUU, then I have no idea on who to
contact later.
Cullen: No one has given a reason why we need an AoR in
the GRUU. 
(More discussions ensued regarding whether obfuscation
and anonymous properties of the GRUUs are generally good
or bad).
Proposal from chair (dean): No reqs to find AOR from GRUUs,
let's discuss it out of scope.
(More discussion ensued since it was deemed that the cat
is already far out of the bag).
This issue was deemed unsolvable at the current time,
list discussion to ensue.

Robert Sparks, Addressing the Remaining Non-INV Transaction
Issues

nit-problems and not-actions with IESG; some solutions have
been started to develop that have been captured in
nit-future drafts.

Robert would like to decline alternative B (allow NIT to
pend), document why in the draft.  Accept and refine
Timeleft concept.  Don't define general "Try again
later" behavior.  Pursue address success and failure caching.

Alternative B creates too much havoc to existing proxies
and should not be used (we should document this for
posterity and move on).  Robert asked some folks who have
declined alternative B to send some text on this.

Accept the Timeleft concept - new header indicating how
much time the downstream element has left.
Adam: not a good idea - if we don't get any hints from
proxies who are not aware of this extension, we will go
round in circles.
Robert called for a hum on if this work should continue
or not.  The hum was for this work NOT to continue.

Success and Failure caching: goal - allow next NIT to
avoid non-responding address.  Question is how often
to probe the non-responding address?  No concrete way.
Jonathan: Use Jenning's outbound I-D.
Cullen: May work for UA - Proxy, but Proxy-Proxy may
not quite work.
Robert: My proposal is for now carry a blacklist; put
these addresses in a cache with a timeout (let the
developer determine the timeout).  And we continue
to pursue Cullen's outbound I-D as a possible better
answer.
Rohan: Would people feel comfortable if the blacklist
applied only if you don't have other alternative?
Robert: We will use some weighted back to list
algorithm that will be fleshed out on the mailing list.

Robert: Abandon general try again later mechanism?
Hum on should we pursue it?  Hum indicated no.

REFER with no Implicit subscription, Orit Levin

This I-d has been discussed many times; it was LC'd
a month ago; all comments incorporated except one
thread raised last week.

How does REFER-Issuer enable the feature?  a) Commonly
preceded by OPTIONS, b) supported header in the
request, c) required header in the response, d) require
header in the requst.

Cullen: Do UAs still use OPTIONS today?  Why not just
send a REFER.
(UAs usenot mandated just because a supported header field is
present.  Better to send a REFER requst with an
explicit "CreateSUB = NO" parameter.
Rohan (ventriloquing through Robert): normal use of
Supported is to list features you support
(...Lots of discussions on the mic on how to signal
intent...)

Dean (as chair): Pre-empted the participants in the discussion
to go out and discuss this in the hallway to reach
an equitable conclusion.  Meanwhile, the next presentation
got the floor as the WG is 25 minutes behind schedule...

(Aside: the participants that went out in the hallway did
reach a conclusion -- yay!  The conclusion is:

  Add a new Refer-To header field
  Keep option tag
  Including this option tag in Require header is NOT
  RECOMMENDED.)


Resource Priority Header, James Polk

2 weeks shy of 5th anniversary of this I-D!  Discussed
changes from previous version (see slides).
The current I-D is -06; -07 will be submitted March 14
and will contain a lot more cleanup with some more
introductory motivational text.

Henning: -07 should be ready for WGLC.  For those who
care, please approach us and let us know of any
concerns.  If someone can read this as an innocent
bystander and provide comments...

Dean: Does everyon who cares about this draft thinks
thier issue has been met.
Appears that folks who care about this draft do not
have any more issues.

Jon Peterson, SIP Identity

New version of sip-identity (-04) -- added new response
codes, softened 'direct TLS connection' requirement;
added support for Content Identifier URI in Identity-info;
added some non-normative text about request in the
backwards direction within a dialog.

(...Discussion on the mic about the interaction of
forking and returning a correctable error response
back to the upstream entity; summary of this discussion:

1) we want proxies to be able to resubmit in response
to the new error codes defined in the draft when
the authenticated role is instantiated by the proxy server

2) Generally speaking, when there is a forking proxy
server after the authentication service, the same rules
that apply for sending responses should apply here as well,
albeit correctable error responses should be preferred.)

New open issues:
1) Display name handling - should identity signature
cover the display name?  All clients (MS Outlook,
for instance) use the display name, and not the name-addr.

Jonathan: Usually a good thing; the service provider
bears the burden of coming up with the display name
and the client is provided a bit-by-bit rendering of
the display name.

(...The discussion converged around providing display
name, and in the display name, just put quoted strings
and prohibit LWS; in the security section there should
be a discussion of the disadvantages of including
display names (account minting a la Yahoo!)...)

2) Applicability to REGISTER - why provide authentication
info to a authentication server as well as my registrar.
Why not do it at one place?
(...Discussion ensued, did not reach any conclusion...)

What is response identity -- have not submitted a draft;
not sure what to do here.  A response identity would
let the UAC know that the response came from an impersonator.
Response identity is hard -- issues: who are you impersonating
when you forge a response?  Requests usually emanate from
one point, responses may come from many.  Furthermore,
what are intermediaries authorized to do when routing
SIP responses?  Plus Contact URIs, AoRs just make the problem
harder.  Impersonating responses requires a great deal
more sophistication (need dialog identifiers).  What is
the solution space?  1) Increase transaction security
2) Provide a causal trace of intermediary agency (like
request-history) 3) Let UAC explore new targets for
a request rather than an intermediary, 4) Do nothing.
Leaning more towards 1) than anything else at this point.

Jonathan: We need a connected party indicator and
strategy 1).
Rohan: We have had consensus that we should address
connected party for a long time; we do not have to do
one of this -- we can implement 3) in an optional way.

Accept Disposition, Gonzalo Camarillo

Went through motivation.
Accept-Disposition header field applicable to the request
the response applies to.
Discussion ensued on the mic between Henning and
Gonzalo; the proposal outlined by Gonzalo:
Proposal: stick to the option tag for right now; later
we look at the underspecification of disposition handling
to see if it is useful to do something else.
No one object to the proposal.