RE: [Sip] Draft minutes of SIP meeting at IETF 62

["Orit Levin" <[e-mail]>]

The REFER extension topic reads:
"Add a new Refer-To header field"

According to my understanding it should be:
"Add a new header to be used with REFER request and the corresponding
response"

Comments?
Orit.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
Dean
> Willis
> Sent: Tuesday, April 05, 2005 10:20 PM
> To: [e-mail]
> Cc: [e-mail]; Gonzalo Camarillo; Allison Mankin
> Subject: [Sip] Draft minutes of SIP meeting at IETF 62
> 
> The following are the draft minutes. Please send any required
> corrections by COB August 7, 2005.
> 
> Revisions will be posted as processed at:
> 
>
http://www.softarmor.com/sipwg/meets/ietf62/notes/minutes-sip-ietf62.htm
l
> 
> -----
> 
> Minutes edited by Dean Willis based on notes by Paul Kyzivat, Spencer
> Dawkins, Vijay Gurbani, Amy Pendleton, and Migual Angel Garcia-Martin.
> 
> Monday, 1930-2200
> 
> Topic: Agenda Bash and Status
> by Chairs
> Slides presented and to be included in proceedings.
> 
> Agenda accepted as presented.
> 
> Chairs reviewed status of current work. It was noted that the current
> charter and milestones are completely obsolete, despite having had
> changes submitted several times by the chairs and the ADs. Apparently
> there is some sort of process problem with the IETF web site.
> 
> 
> 
> 
> Topic: GRUU Remaining Issues (Knowing AOR, Rewriting by SBC, etc.)
> by Jonathan Rosenberg
> see draft-ietf-sip-gruu-03.txt
> Slides presented and to be included in proceedings.
> 
> Changes to previous doc reviewed. The redundancy issue has been
> declared out of scope, and discussion suggested that this should
> perhaps be placed into the Jennings "outbound" draft. The current
> model assumes that both "sip" and "sips" versions of a GRUU are
> created when a GRUU is, and that they route to the same resource. The
> URI scheme of the "To:" header is used to select the appropriate
> GRUU. It was suggested that this should be clarified in RFC 3261,
> perhaps as an errata.
> 
> Several record-routing cases were discussed based on slides. There was
> inconclusive discussion of a scenario where the use of GRUU creates an
> undesirable "tromboning" effect back to the upstream entity after
> resolution
> 
> 1) Open Issue: Discovering AoR from A GRUU
> 
> Discussed issue about getting AOR from gruu - why this is/isn't a
> need.  Objections were raised to the proposed compromise in the
> draft. Various other alternatives discussed. Cullen Jennings didn't
> see a compelling reason for it. Paul Kyzivat (who had raised the issue
> initially) said he no longer found this a need- solutions other than
> GRUU were sufficient. Aki Niemi and Orit Levin still expressed a
> desire for this feature. Dean, as chair, said we have no requirement
> for this, and a domain can do it anyway if it wants. Inconclusive
> discussion followed.
> 
> 2 )Open Issue: relationship of Identity to GRUU
> 
> The relationship between these two elements was discussed without
> conclusion, although Jon Peterson (author of the Identity work)
> asserted an pinion that a GRUU and an identity are not the same thing.
> 
> 
> 
> 
> Topic: Non-Invite Transactions
> by  Robert Sparks
> see draft-sparks-sip-nit-future-01.txt
> Slides were presented and should be included in the proceedings.
> 
> 1) Proposed that we accept and refine Time left concept, and not
define
> general "Try again later" behavior. This approach uses a new header
> indicating how much time the downstream element has left.  Adam roach
> argued that it was 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 consensus was for neither the timeline nor the "try again
> later" work to continue.
> 
> 2) Proposed that we pursue address success and failure caching.  The
> goal is to allow next NIT to avoid non-responding address.  Question
> is how often to probe the non-responding address?  No concrete way.
> Jonathan Rosenberg proposed that we use Jenning's outbound I-D.
Cullen
> Jennings stated that this may work for UA - Proxy, but Proxy-Proxy may
> not quite work. Robert Sparks proposed that for now we 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. Discussion followed. The
> conclusion was that for now we will use some weighted back to list
> algorithm that will be fleshed out on the mailing list.
> 
> 
> 
> Topic: REFER Extensions
> by Orit Levin
> see draft-ietf-sip-refer-with-norefersub-01.txt
> Slides were presented that should be included in proceedings.
> 
> Only one open issue remained for the draft since its WGLC. This was
> "How does a REFER-Issuer enable the feature?". Alternatives include:
> a) Commonly preceded by OPTIONS, b) supported header in the request,
> c) required header in the response, d) require header in the request.
> 
> Discussion agreed that the Supported header is the wrong approach, as
> it indicates which features are supported by the sender, not required
> for the respondent.
> 
> Discussion became prolonged, and the participants were moved to the
> hallway for a focused discussion. This discussion reached the
> following conclusion:
> 
>    1) Add a new Refer-To header field
>    2) Keep option tag
>    3) Including this option tag in Require header is NOT RECOMMENDED.
> 
> This conclusion was shared with the WG, and no objections were noted.
> 
> The "hallway" conversation necessitated a slight juggling of the
> agenda, with resource Priority being discussed during the hallway
> discussion.
> 
> 
> Topic SIP Resource Priority
> by James Polk
> See: draft-ietf-sip-resource-priority-06.txt
> Slides were presented and should be included in proceedings
> 
> It was noted that this draft is just 2 weeks shy of its 5th
> anniversary, making it one of our longer-lived discussions. Changes
> since previous version were discussed. The plan of record is to submit
> and WGLC a revision of this draft with minor cleanup as proposed
> here. The authors requested: "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, please do".
> 
> The chairs polled the room: "Does everyone who cares about this draft
> think their issue have essentially been met?" The consensus of the
> room was favorable and no issues were raised. It should be noted that
> Mike Pierce, a long time participant in this discussion, was not
> present as of this poll.
> 
> 
> 
> Topic: Request Identity
> by Jon Peterson
> See: draft-ietf-sip-identity-04.txt
> Slides were presented and should be included in the proceedings.
> 
> 
> 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 noted that this is 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. Following
> discussion indicated a strong consensus to protect the display name if
> feasible.
> 
> The consensus was to protect display name, and in the display name,
> just put quoted strings and prohibit LWS. In the security section of
> the draft 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 to the registrar? Jonathan Rosenberg
> presented an acceptable use case, and the authors concluded that they
> would amend the draft to indicate the usability of Identity in
> REGISTER transactions.
> 
> 
> 
> Topic: Response Identity
> by Jon Peterson
> 
> No slides presented.
> 
> Jon lead a discussion about the meaning and critical aspects of
> response identity.
> 
> Jon says he has lost his way on this draft. The sip-identity work
> doesn't work for responses because of retargeting. Who do responses
> actually come from?  What are intermediaries allowed to do when
> routing SIP requests? How would a UAC make authentication decisions
> based on response identity?  Anyone can impersonate a requester, but
> impersonating a responder is a lot harder - need dialog identifiers,
> etc.  Improve channel security to make it even harder to impersonate a
> responder? Provide causal trace after-the-fact? Let UAC explore new
> targets for a request?  Assume bar is high enough for impersonators
> now? - what if the real responder tries to impersonate someone else?
> 
> Jonathan Rosenberg said major threat is if someone fakes a connected
> party id, assuming we had that, and that such is a requirement. Rohan
> Mahy thought History-Info is the right solution and said he plans to
> write up something about it.
> 
> 
> Consensus: We're generally headed in the right direction but have a
> long way to go.
> 
> 
> 
> Topic: Accept-Disposition
> by Gonzalo Camarillo
> See: draft-camarillo-sip-accept-disposition-00.txt
> Slides presented and should be included in proceedings
> 
> 
> open question: How do we say we don't understand content-disposition?
> Add Accept-Disposition (equivalent to Accept header)?  We have several
> ways to require support for something - method, option tag, body with
> handling=required. Want to pick one and clarify content disposition
> handling Combining two problems - Accept is used as hint about how you
> goofed. Isn't Warning closer to what we're getting at? Accept headers
> became useless because everyone Accept: * (everything). Don't we
> really want an explicit code that tells us what we want to know?  How
> to tell refusal from lack of comprehension?  What is scope of
> Accept-Disposition?
> 
> 
> Conclusion: Rather than pursue this approach, for the application
> (exploder) that stimulated this draft there was a decision to use an
> option tag to negotiate support for the needed combination of
> features.
> 
> Separately, there was interest by some (at least Gonzalo and Paul) in
> starting to investigate the underspecification of Content-Disposition.
> 
> 
> 
> 
> 
> Tuesday, 1300-1500
> 
> 
> Agenda by Chairs Agenda accepted as proposed in slides. The proposed
> topic of "Connection Reuse" was withdrawn by author Rohan Mahy. If
> time allows, a discussion of retargeting led by Jon Peterson will be
> undertaken.
> 
> 
> 
> Topic: SIP Interaction Framework
> by  Jonathan Rosenberg
> See: draft-ietf-sipping-app-interaction-framework-04.txt
> Slides presented and should be included in proceedings
> 
> The current state of the draft has raised a requirement for other work
> that Jonathan calls the "target dialog" approach and has fleshed
> out. Discussion of this approach ensued. Alan Johnston noted that an
> option tag is needed. Robert Sparks spoke in favor of the
> approach. Following discussion, the chairs polled the room and a
> consensus to proceed with this approach was reported. The chairs are
> instructed to work with the Area Director to add the target dialog
> draft to the working group charter.
> 
> 
> Topic; Management of Outbound Connections
> by Cullen Jennings
> See: draft-jennings-sipping-outbound-01.txt
> Slides were presented and should be included in proceedings
> 
> Open issue: Do we need an option tag to know if registrar supports
> flow-id and if UA supports this.  Rohan argued against the option
> tag. Jonathan proposed that it would be needed it in the Require in
> the REGISTER.  Rohan countered that one could check in the response
> what it came back, and perhaps add a Contact header field parameter to
> discover if the functionality is supported by the registrar.  Alan H.
> noted that if the registrar does not support the functionality, you
> end up with a wrong binding that you have to fix later.
> 
> After discussion, there were no sustained objections to adding an
> option tag, and a quick poll indicated consensus for this
> approach. Cullen agreed to make this change in the next revision.
> 
> 
> Topic: Using Certificates with SIP
> by Cullen Jennings
> see draft-ietf-sipping-certs-01.txt
> Slides were presented and should be included in proceedings
> 
> 1) Robert Sparks commented that the draft needs further text about
> caching certs, and checking certificate revocation.
> 
> 2) Jon Peterson suggested that we make sure to clarify subscription
> duration, which Cullen noted should not cache beyond validity time
> 
> 3) Rohan observed that we need to refresh the subscription even if the
> cert is still is valid, when there hasn't been a NOTIFY for some long
> period of time.
> 
> 4) Francois Audet noted issues with retargeting and forking. For
> example,the sales group example does not work properly. An other case
> is retargeting. Use case: the help desk. You don't care who is going
> to answer, but the requirement is the conversation to be
> encrypted. Cullen observed that the assumption of this draft is indeed
> that all devices for the ID have the same credentials. Jon Peterson
> suggested that RFC 3261 with SIPS resolves theses cases. Cullen
> observed that there are separate problems: a) to determine who the
> certificate belongs to, and b) acquiring the certs. This draft
> addresses only b.  It was resolved that the scope of the draft should
> be clarified, and that we should change the name to "credential
> management" instead of "certificate management".
> 
> 5) Jonathan asked:"What happens if I send a SUBSCRIBE for a GRUU? Do I
> get the cert for the AOR?" Cullen responded that the draft discusses
> users, not devices. Jon Peterson stated that this problem should be
> resolved in the identity draft, not here.
> 
> 
> 
> Topic: End-to-middle security
> by Kumiko Ono
> see draft-ono-sipping-end2middle-security-04.txt
> Slides were presented and should be included in proceedings
> 
> Chairs noted that they expect this work to migrate from SIPPING to SIP
> fairly soon, as has gone beyond the requirements consensus and into
> implementation.
> 
> 1) Open issue: Signatures inside, encryption outside or the other way
> around?
> 
> Jon reported that we did some analysis about this when drafting RFC
> 3261, and think the signature should go inside, the encryption
> outside.  Cullen believes that signature inside the encrypting part
> will give better security properties (from the security group).
> Catherine also stated that the crypto community thinks signature
> inside is generally better, although there are sometimes exceptions.
> 
> Conclusion: consensus to have signature inside.
> 
> 2 )Open issue: How a proxy can tell a UA to disclose a body while
> protecting data integrity?
> 
> Options include new error response, existing resp with warning header,
> or existing resp instruct UA one task at a time.
> 
> 
> James Polk asked if we could use CID and Reason header? Jon Peterson
> noted that CID is valid is the scope is a partial body of the
> multipart, but if you talk about the whole body, you don't need a CID.
> 
> Dean asked: can the proxy request a body? Jon responded: if it is
> undecipherable, how can it point to one body? The proxy only knows the
> whole multipart body, not the individual parts. It is better to do it
> at the high level -- the proxy says I need to read this body, without
> indicating which one.
> 
> Dean and Jonathan noted that Content-Disposition may also be
applicable.
> 
> No conclusion noted for this issue.
> 
> 
> Chairs Poll: This is a proposal for an implementation of the
> end-to-middle requirements established by SIPPING. Do we wish to adopt
> this as a working group item? A consensus in favor of adoption was
> reported, and the chairs are instructed to work with the D to get this
> item added to the SIP WG milestone list.
> 
> 
> 
> Topic: Extension Negotiation
> by Volker Hilt
> See: draft-hilt-sip-ext-neg-00.txt
> 
> Slides were presented and should be included in the proceedings.
> 
> Discussion followed.
> 
> Paul K noted that this aggregates on not being clear of what is the
> scope of what an Accept header is. Does it apply to OPTIONS?  Severe
> discussion about when to include or not the Accept header, in which
> methods.  Jonathan replied: There is not a not clear answer, but
> interoperability is maximized when you put everything you support in
> the header. OPTIONS carries a permanent scope: this is what I support.
> Gonzalo observed that, at the end of the day what we want to disclose
> is the desired Content-Disposition.  Dean also observed that RFC 3261
> scopes the Accept header to the duration of a dialog and that RFC 3264
> scopes the Accept header for the duration of a SUBSCRIBE dialog.
> 
> Dean suggested that this would be a good time time to have guidelines
> for Accept headers. Cullen and Jonathan maintain that it is simpler to
> populate the Accept header with everything that is supported, even if
> this set becomes very large.
> 
> Jonathan clarifies that the use case is when the server can provide an
> alternative extension in case the client does not support a given
> extension. The example: if the presence server knows that the client
> does not support RPID, then the server might put the contents of
> activity elements in note elements.
> 
> Adam noted that there is currently no way for the server to determine
> that something is not supported at the client.
> 
> There does not seem to be a clear path forward, and we should perhaps
> look more closely at use cases.
> 
> 
> 
> Topic: Retargeting
> by Jon Peterson
> Slides presented and should be included in proceedings.
> 
> Discussion followed.
> 
> Rohan Mahy observed that sometimes an unanticipated respondent is a
> desirable outcome. And sometimes it isn't.
> 
> Keith Drage proposed that response identity should be connected party
> ID.
> 
> 
> Jon observed that the response identity problem is defined as the
> ability from the UAC to determine that the response came from an
> impersonator. Implementation of connected party is likely to occur
> security problems, and a UAC doing wrong authorizations.
> 
> Jonathan suggested that we reduce the scope of the requirements to
> something that we can solve today. There are other harder problems
> that we can't solve today.
> 
> Jon proposed that we need to solve the problem that ends up in SRTP,
> starting from SIP identity, SIP certs, Mikey, SRTP.
> 
> Discussion of endpoint vs proxy trust followed, with the general
> consensus being that, at least to some extent, proxies must be
> trusted, because "the SIP proxy allocates you with a SIP URI and can
> take it out of you at any time".
> 
> Jon proposed that we takes this work as an informational document in
> SIPPING discussing the kind of attacks.
> 
> Jonathan noted that we need to update the SIPS behavior in SIP, there
> are a few open holes.
> 
> Jon restated that the scope of this work is to detect that there has
> been a retargeting, not to prevent that retargeting to happen.
> 
> No further conclusions were noted.
> 
> 
> The meeting of the SIP working group concluded on schedule.
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip