Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment]

From: [email-masked]
Date: Tue, 18 Jun 2002 11:36:30 +0300

I agree with the changes. Just a couple of minor nits:

Section 2 mentions that a "REFER might create a dialog". Might? Should it say "MAY" or better extent this sentence to say "REFER creates a dialog when an implicit subscription has been created."

Also section 2 references section 2.4.5 referring to the section of the cases when a REFER implicitly establishes a subscription. Should that reference be sections 2.4.1-2.4.3? (Section 2.4.5 actually describes the behaviour once a subscription has been created).

Section 2.4.5 Its not clear that a SUBSCRIBE is used to refresh and not a REFER. How about "The agent issuing the REFER may extend its subscription by sending a SUBSCRIBE request using the subscription refresh mechanisms described in [2]." 

Regards,
Hisham

> -----Original Message-----
> From: ext Robert Sparks [mailto:[email-masked]]
> Sent: Monday, June 17, 2002 5:14 PM
> To: [email-masked]
> Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip]
> Referstatus/adjustment]
> 
> 
> The message I sent last week (copied below) 
> has generated no list comments. I hope it
> was because I was too subtle with the subject
> line.
> 
> I have asked the IESG to delay their consideration
> of the REFER draft until these concerns have been
> discussed on this list.
> 
> Please read the draft below and comment. If you 
> agree with what's in the draft, please post a
> note saying so.
> 
> RjS
> 
> -----Forwarded Message-----
> 
> > From: Robert Sparks <[email-masked]>
> > To: [email-masked]
> > Subject: [Sip] Refer status/adjustment
> > Date: 12 Jun 2002 13:49:35 -0500
> > 
> > A set of converging concerns were raised about the 
> > REFER draft late in the review process, all centering
> > on draft's use of sip-events (soon to be RFC3265) and
> > the implicit subscription.
> > 
> > When investigating those concerns, several things became
> > clear. 
> > 
> > The draft did not provide sufficient discussion
> > around managing the lifecycle of the implicit subscription
> > (Can you refresh the implicit subscription? unsubscribe?
> >  How is the Subscription-State header supposed to be used?
> >  How do the two parties know when the subscription is over?)
> > and the draft did not clearly specify some of the things
> > RFC3265 requires of an event package. These need to be
> > corrected.
> > 
> > A larger issue centers around the following language from
> > sip-events:
> > 
> >   Note that any behavior designated with "SHOULD" or "MUST" in this
> >   document is not allowed to be weakened by extension documents;
> >   however, such documents may elect to strengthen "SHOULD"
> >   requirements to "MUST" strength if required by their application.
> > 
> > The current draft is not clear enough on one particular point - the
> > examples do not show immediate NOTIFYs for the implicit 
> subscription.
> > I expect that many members of the community believe they are not 
> > required (I had drifted into thinking that way before the comments
> > caused me to look at this more closely). The normative text in the
> > current REFER draft calls to RFC3265, and immediate NOTIFYs are very
> > clearly required there. This needs to be pointed out more clearly
> > in the REFER draft.
> > 
> > Finally, the current draft makes instantiating a subscription a
> > SHOULD strength requirement, but provides no mechanism for the
> > agent sending the REFER to know whether or not to expect a NOTIFY.
> > We have repeatedly had discussions on the list about how long
> > the agent sending the REFER should keep state waiting for a NOTIFY -
> > and with discomfort deciding that is an implementation decision. 
> > Recent discussions have pointed out that there is disagreement about
> > what never receiving a NOTIFY means - should the REFERing 
> party treat
> > that as an error and re-attempt the reference or should it just
> > assume no subscription was created? 
> > 
> > I've put together an individual submission that adds all the
> > above clarifications. It also proposes a new mechanism to 
> > address the problems in the previous paragraph. Basically, it
> > provides a way for the party sending the REFER to indicate
> > that it really wants to be notified, and a way for the agent
> > accepting the refer to signal that it will or will not send
> > notifies in the response to the REFER.
> > 
> > I just submitted this draft - until it appears in the repository,
> > you can get it from
> > 
> http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265di
sc-00.txt
> 
> I propose that this draft replace refer-05 before it advances further
> in the standardization process.
> 
> RjS
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Rob Phillips" <[email-masked]>
Date: Tue, 18 Jun 2002 08:54:04 -0500

I have a nit on the Examples section of 2.1.  The following two examples don't parse:

         Refer-To: sip:[email-masked]?Accept-Contact%3Dsip:bobsdesk.
                   biloxi.com&Call-ID%3D55432%40alicepc.atlanta.com

         Refer-To: sip:[email-masked]?Replaces%3D12345%40192.168.118.3%3B
                   to-tag%3D12345%3Bfrom-tag%3D5FFE-3994

I think what you would want to have would be something like this:

         Refer-To: sip:[email-masked];method=REFER?Accept-Contact%3Dsip:bobsdesk.
                   biloxi.com&Call-ID%3D55432%40alicepc.atlanta.com

         Refer-To: sip:[email-masked];method=REFER?Replaces%3D12345%40192.168.118.3%3B
                   to-tag%3D12345%3Bfrom-tag%3D5FFE-3994

Also, while this is pretty well spelled out in the document, I'd like to see somewhere (either in section 2.1 or 2.2) where you have this information:

	Header field     where     REFER
	____________     _____     _____
	Refer-To           R         m

- rob

---

From: [email-masked]
Date: Tue, 18 Jun 2002 17:09:53 +0300

> From: ext Rob Phillips [mailto:[email-masked]]
> Sent: Tuesday, June 18, 2002 4:54 PM
> To: [email-masked]
> Cc: Robert Sparks
> Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip]
> Referstatus/adjustment]
> 
> 
>          Refer-To: 
> sip:[email-masked]?Replaces%3D12345%40192.168.118.3%3B
>          Refer-To: 
> sip:[email-masked];method=REFER?Accept-Contact%3Dsip:bobsdesk.
>          Refer-To: 
> sip:[email-masked];method=REFER?Replaces%3D12345%40192.168.118.3%3B

This is wrong. method=REFER in this case means that you are asking the referee to send a REFER.

This is what you want
Refer-To: 

> sip:[email-masked];method=INVITE?Replaces%3D12345%40192.168.118.3%3B

But since INVITE is the default, then its not needed. If you want to refer someone to subscribe to someone else, then you would have

Refer-To: 
> sip:[email-masked];method=SUBSCRIBE

By the way, do we need <> around the sip uri examples there?

Regards,
Hisham

---

From: "Rob Phillips" <[email-masked]>
Date: Tue, 18 Jun 2002 09:50:20 -0500

>But since INVITE is the default, then its not needed.

Forgive my ignorance here, I'm mainly concerned with the parsing of the request as opposed to how it works, which is why I chose "method=REFER".

I see that this seems to be the case for other examples as well in the SIP draft, but where is it listed that the uri-parameter field is optional?  In the BNF, the uri-parameters field is listed as a mandatory field:

        SIP-URI          =  "sip:" [ userinfo "@" ] hostport
                            uri-parameters [ headers ]
        SIPS-URI         =  "sips:" [ userinfo "@" ] hostport
                            uri-parameters [ headers ]

And at least in bis-09 section 19.1.1, there isn't a reference to the uri-parameters field being optional.  So is this a problem with bis-09?  It's certainly an inconsistency.

- rob

---

From: "Rob Phillips" <[email-masked]>
Date: Wed, 19 Jun 2002 09:42:04 -0500

>By the way, do we need <> around the sip uri examples there?

I think the answer is yes.  There's a paragraph in bis-09 chapter 20 that seems to support this:

   The Contact, From, and To header fields contain a URI. If the URI
   contains a comma, question mark or semicolon, the URI MUST be
   enclosed in angle brackets (< and >). Any URI parameters are
   contained within these brackets. If the URI is not enclosed in angle
   brackets, any semicolon-delimited parameters are header-parameters,
   not URI parameters.

I think that, although the first sentence gives the impression this paragraph is meant only for the Contact, From, and To headers, it's a general comment on URIs in SIP.  Would this be the consensus?

- rob

---

From: [email-masked]
Date: Thu, 27 Jun 2002 15:59:37 +0300

Sory, I meant to say

Why can't we use the event-header in REFER/200 instead of Supported and Require headers? If event-header is not returned in the response, no implicit subscription is created.

Hisham

> From: ext [email-masked] 
> [mailto:[email-masked]]
> Sent: Thursday, June 27, 2002 3:58 PM
> To: [email-masked]; [email-masked]
> Why can't we use the event-header in SUBSCRIBE/200 instead of 
> Supported and Require headers? If event-header is not 
> returned, no implicit subscription is created.
> 
> Regards,
> Hisham
> 
sc-00.txt

---

From: [email-masked]
Date: Thu, 27 Jun 2002 15:57:37 +0300

Why can't we use the event-header in SUBSCRIBE/200 instead of Supported and Require headers? If event-header is not returned, no implicit subscription is created.

Regards,
Hisham

> > I just submitted this draft - until it appears in the repository,
http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt