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

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jun 2002 11:29:46 -0400

Look more closely at the definition of "uri-parameters".

        uri-parameters    =  *( ";" uri-parameter)

See that "*" in the front? That means "zero or more." And zero happens
to be a very popular choice for this particular case.

/a

> -----Original Message-----
> From: Rob Phillips [mailto:[email-masked]]
> Sent: Tuesday, June 18, 2002 9:50
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip]
> Referstatus/adjustment]
> 
> 
> >This is what you want
> >Refer-To: 
> >> 
> sip:[email-masked];method=INVITE?Replaces%3D12345%40192.168.118.3%3B
> >>                    to-tag%3D12345%3Bfrom-tag%3D5FFE-3994
> >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
> 
> _______________________________________________
> 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: Adam Roach <[email-masked]>
Date: Thu, 27 Jun 2002 13:01:41 -0400

Because that's not really what Event means. Event means
"you *can* subscribe to this event", not "you have been
forcibly subscribed to this event, possibly against
your will".

/a

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 27, 2002 8:00
> To: [email-masked]; [email-masked]; [email-masked]
> 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
> > 
> > > 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
> > 
> > 
> > 
> > 
> > 
> > 
> >