You appear to be questioning whether the solution was adopted. The minutes
state:
-------------------------------------------------------------------
Topic: GRUU and Supporting Drafts
Led by Jonathan Rosenberg
Slides included in proceedings
Read: draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00
Change since last version reviewed.
Issue: GRUU subtype names. The room demonstrated a slight preference
for the names used in -11 over known alternatives, but nobody seems
particularly enamored with these names and the floor remains open to
suggestions.
Discussion on ua-loose-route draft deferred to next session.
Session 2: Friday 0900-1130 Grand Ballroom C
Topic: UA-loose-route, continued from previous session.
Consensus noted that we do need some sort of solution for the general
problem of delivery of URI parameters across contact-routing
operations.
Issue: Concerns raised about backward compatibility. Noted that
compliant P-CSCF should be OK. Suggested that we have a design team
revisit call-flows and analyze for backward compatibility issues.
Issue: Does GRUU normatively depend on this work? Resolved: GRUU does
not reference this document. However, some participants feel it
should, as the benefit of GRUU cannot be fully recognized in the
absence of this specification. The chairs asked for a hum, and the
consensus of the room is that GRUU and ua-loose-route can proceed
independently.
Question: Adopt this draft as baseline text for a WG effort, should
the ADs approve the milestone? Consensus to adopt noted by
chairs. To-do: Chairs to work with AD to set new milestone.
----------------------------------------------------------------------
The minutes quite clearly say "Adopt this draft as baseline text for a WG
effort" and given that the charter item now exists, then I believe that we are
entitled to call for the editor (Jonathan) to submit the current text as
draft-ietf-sip-ua-loose-route.
I agree the file name says loose-route, but I don'y think we should change
that. After all, we lose that filename when it gets published as an RFC anyway.
The charter item states
Dec 2007 Delivering request-URI and parameters to UAS via proxy to WGLC
Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS)
I assume that you are OK with this.
What I would suggest is that you address specific comments to the title of the
deliverable:
Applying Loose Routing to Session Initiation Protocol (SIP) User Agents
(UA)
And to the abstract:
Abstract
A key part of the behavior of the Session Initiation Protocol (SIP)
is that SIP proxies rewrite the Request-URI as a request moves
throughout the network. Over the years, experience has shown this to
be problematic. It makes it difficult to use Request URI for service
invocation, complicates emergency services, makes it more complex to
support aliases, and so on. Architecturally, it confounds the
concepts of address and route. This document proposes to change this
through a new mechanism called UA loose routing.
As you think appropriate to your concerns.
Alternatively, if you (or indeed any other SIP WG member) do have a completely
different solution, then there is still time to post an individual draft or
post a skeleton of a mechanism to the list.
Regards
Keith
> -----Original Message-----
> From: Christer Holmberg (JO/LMF)
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 13, 2007 8:52 PM
> To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List
> Subject: RE: [Sip] UA Loose Routing
>
>
> Hi,
>
> We can call it loose route if we want, but I think the
> initial focus should be the problem we are going to solve (I
> don't think we agreed on a specific solution at #67), and we
> should look into alternative solutions (the draft does that
> in some extent, but other possible alternatives have also
> been mentioned).
>
> Or, do you prefer to have separate drafts describing
> alternative solutions for the problem?
>
> Regards,
>
> Christer
>
>
>
> > -----Original Message-----
> > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED]
> > Sent: 13. kesäkuuta 2007 22:25
> > To: Jonathan Rosenberg; IETF SIP List
> > Subject: RE: [Sip] UA Loose Routing
> >
> > (As WG chair)
> >
> > As well as agreeing to charter the item, we actually agreed
> at IETF#67
> > that this draft was a suitable candidate to fulfil that
> charter item.
> >
> > Therefore unless issues are raised with this, I would request the
> > editor (as Jonathan is editor) to submit the next version of this
> > document as draft-ietf-sip-ua-loose-route-00.
> >
> > Regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 13, 2007 4:02 AM
> > > To: IETF SIP List
> > > Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility
> > >
> > > I've recently revised my draft on UA loose routing. You can
> > pick it up
> > > here:
> > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo
> > > se-route-01.txt
> > >
> > > This draft is meant to fulfill one of our charter items:
> > > Feb 2008 Delivering request-URI and parameters
> > > to UAS via proxy to
> > > IESG (PS)
> > >
> > > As folks may recall, the GRUU spec used to have these
> things called
> > > grids, which allowed a UA to add its own parameters to the
> > GRUU before
> > > handing it out. Several GRUU revisions back, this function
> > got yanked
> > > because it was recognized that the problem was more general
> > than GRUU,
> > > and would be useful for AOR as well.
> > >
> > > Two IETFs back I presented this draft briefly during a
> SIP session.
> > > There was a lot of interest and people liked it architecturally,
> > > however there were two open issues that needed to get
> > resolved. This
> > > mail is meant to start discussion on one of them - backwards
> > > compatibility.
> > >
> > > THe mechanism basically changes the way proxies handle requests.
> > > Instead of rewriting the request URI for out-of-dialog requests,
> > > they'll push a route header and leave the r-uri alone. This
> > allows the
> > > original R-URI and any parameters it contains to get
> > delivered to the
> > > UAS.
> > >
> > > So, the main issue is, what kinds of backwards
> > compatibility problems
> > > will this cause. The draft provides a basic mechanism
> whereby a UA
> > > includes an option tag in the REGISTER, and the registrar
> indicates
> > > that it is using this mechanism or not. So we can negotiate this
> > > between a UA and registrar easily. Now, the problem is with
> > > intermediate proxies. If there is an edge proxy between the
> > UA and its
> > > registrar, it will now see requests targeted to the UA,
> > which contain
> > > a Route header beyond itself, even though it thinks its the
> > edge proxy
> > > and the last point of contact before the UA. Technically,
> > if this edge
> > > proxy is compliant to rfc3261 it would work. However, the
> > question is
> > > whether proxies in the wild would properly work in this case.
> > >
> > > If folks can comment based on their own products, or their
> > > experiences, on whether they think this would work, or
> > concerns they
> > > have, that would be great. THere are solutions that would
> > allow us to
> > > disable the mechanism when intermediate proxies don't
> > support it, but
> > > they are more complex and I'd rather avoid it.
> > >
> > > THanks,
> > > Jonathan R.
> > > --
> > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> > > Cisco Fellow Parsippany, NJ
> > > 07054-2711
> > > Cisco Systems
> > > [EMAIL PROTECTED] FAX:
> (973) 952-5050
> > > http://www.jdrosen.net PHONE:
> (973) 952-5000
> > > http://www.cisco.com
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use
> > > [EMAIL PROTECTED] for questions on current sip Use
> > > [EMAIL PROTECTED] for new developments on the application of sip
> > >
> >
> >
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > [EMAIL PROTECTED] for questions on current sip Use
> > [EMAIL PROTECTED] for new developments on the application of sip
> >
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
