Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

I meant UAS not UAC

----- Original Message -----
From: Andrew Allen [mailto:aallen@blackberry.com]
Sent: Tuesday, August 12, 2014 01:38 PM Eastern Standard Time
To: ietf.shinji@gmail.com <ietf.shinji@gmail.com>; sipcore@ietf.org <sipcore@ietf.org>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

I think that's clear. The RFC 6665 UAC acts as per RFC 3515.  See RFC 6665 4.2.1

----- Original Message -----
From: OKUMURA Shinji [mailto:ietf.shinji@gmail.com]
Sent: Tuesday, August 12, 2014 10:38 AM Eastern Standard Time
To: sipcore@ietf.org <sipcore@ietf.org>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Hi,

I have another question.

If 6665 compliant UAS receives a REFER request within an
existing dialog that would create an implicit subscription,
how should the UAS handle the REFER request?

Regards,
Shinji

> Adam and I spent some time today editing to account for the discussion.
>We believe we covered all the concerns raised.
>
>The sentence in section 3 was getting a bit complex, so we split it up into 
>several.
>Here's what it was before splitting it up:
>
>A UA that will accept a subscription-creating REFER request needs to include
>a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER 
>requests
>related to any dialog created by the INVITE arrive at this UA.
>
>You can see what it turned into by looking in the draft.
>
>RjS
>
>
>-------- Original Message -------- Subject: New Version Notification for 
>draft-sparks-sipcore-refer-clarifications-03.txt
> Date: Mon, 28 Jul 2014 15:16:04 -0700
> From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org
> To: Robert Sparks [a:mailto:rjs@nostrum.com]<rjs@nostrum.com>, "Adam Roach" 
>[a:mailto:adam@nostrum.com]<adam@nostrum.com>, Adam Roach [a:mailto:
>adam@nostrum.com]<adam@nostrum.com>, "Robert Sparks" [a:mailto:RjS@nostrum.
>com]<RjS@nostrum.com>
>
>
>A new version of I-D, draft-sparks-sipcore-refer-clarifications-03.txt
>has been successfully submitted by Robert Sparks and posted to the
>IETF repository.
>
>Name:		draft-sparks-sipcore-refer-clarifications
>Revision:	03
>Title:		Clarifications for the use of REFER with RFC6665
>Document date:	2014-07-28
>Group:		Individual Submission
>Pages:		4
>URL:            [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-03.txt
>Status:         [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/
>Htmlized:       [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-03
>Diff:           [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-03
>
>Abstract:
>   An accepted SIP REFER method creates an implicit subscription using
>   the SIP-Specific Event Notification Framework.  That framework was
>   revised by RFC6665.  This document highlights the implications of the
>   requirement changes in RFC6665, and updates the definition of the
>   REFER method, RFC3515, to clarify and disambiguate the impact of
>   those changes.
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore