Re: [SIP] harmonized SUBSCRIBE/NOTIFY behavior

["rahnkp" <[e-mail]>]

Please do not send this stuff to me. It's all very interesting, but I am not
connected to you folks...
Thanks
----- Original Message -----
From: Rohan Mahy <[e-mail]>
To: <[e-mail]>
Sent: Thursday, July 06, 2000 1:16 PM
Subject: [SIP] harmonized SUBSCRIBE/NOTIFY behavior


> Hi,
>
> I'm looking for some consistent direction on SUBSCRIBE/NOTIFY.  Since we
> have the SUBSCRIBE/NOTIFY draft, PINT, and IMPP for presence, all doing
> stuff differently.
>
> I can see valid reasons for each of these cases:
>
> a       subscribe to ongoing state, I already know the current state
> b       subscribe to ongoing state, plus get current state
> c       refresh subscription, I know the current state
> d       refresh subscription, plus get current state
> e       fetch the current state
> f       unsubscribe
>
> Hopefully Jonathan Rosenberg, Scott Petrack, and Adam Roach have all
talked
> about this somewhere.
> My interetation of the currently available documents is that they can do
this:
>
> SUB/NFY a, c, f
> PINT            a, c, e, f
> IMPP            b, c, e, f
>
> Perhaps we need a new header/parameter used in a SUBSCRIBE that indicates
> whether to send back immediate status?
>
> Also, the use of an Event header, Call-ID usage, and body handling are not
> consistent, but this seems like less of an issue.
>
> Anyone care to clarify?  Will the three documents be harmonized (apologies
> for using an ITU term) at some point?
>
> Relevant sections of the documents are included below.  Also, a short
> comment on IMPP inline...
>
> thanks,
> -rohan
>
>
> In draft-roach-sip-subscribe-notify-00.txt, the author asks:
>
> >Should cancelling a subscription be performed with the UNSUBSCRIBE method
> >defined in PINT for the sake of consistency, or is the REGISTER model of
> >"Expires: 0" preferable?
>
> There is no mention of the SUBSCRIBE response carrying back any state.  In
> the companion document, draft-roach-sip-acb-00.txt, a SUBSCRIBE to the
> "terminal-free" event does not necessarily need state in the reply,
because
> presumably, the subscriber already assumed the terminal wan't free,
because
> they got a busy signal.
>
> In RFC2848, the authors state:
>
> >When a SUBSCRIBE request is sent to a PINT Server, it indicates that a
> >user wishes to receive information about the status of a service session.
> >The request identifies the session of interest by including the original
> >session description along with the request, using the SDP
> >global-session-id that forms part of the origin-field to identify the
> >service session uniquely.
>
> >Rather than have two different methods of identifying the "session of
> >interest" the choice is to use the origin-field of the SDP sub-part
> >included both in the original INVITE and in this SUBSCRIBE request.
> >
> >Note that the request MUST NOT include any sub-parts other than the
> >session description, even if these others were present in the original
> >INVITE request. A server MUST ignore whatever sub-parts are included
> >within a SUBSCRIBE request with the sole exception of the enclosed
session
> >description. The request MAY contain a "Contact:" header, specifying the
> >PINT User Agent Server to which such information should be sent.
> >
> >In addition, it SHOULD contain an Expires: header, which indicates for
how
> >long the PINT Requestor wishes to receive notification of the session
> >status. We refer to the period of time before the expiration of the
> >SUBSCRIBE request as the "subscription period". See section 5.1.4.  for
> >security considerations, particularly privacy implications.
> >
> >A value of 0 within the Expires: header indicates a desire to receive one
> >single immediate response (i.e. the request expires immediately). It is
> >possible for a sequence of monitoring sessions to be opened, exist, and
> >complete, all relating to the same service session.
> >
> >A successful response to the SUBSCRIBE request includes the session
> >description, according to the Gateway. Normally this will be identical to
> >the last cached response that the Gateway returned to any request
> >concerning the same SDP global session id (see [2], section 6, o= field).
> >The t= line may be altered to indicate the actual start or stop time,
> >however. The Gateway might add an i= line to the session description to
> >indicate such information as how many fax pages were sent. The Gateway
> >SHOULD include an Expires: header indicating how long it is willing to
> >maintain the monitoring session. If this is unacceptable to the PINT
> >Requestor, then it can close the session by sending an immediate
> >UNSUBSCRIBE message (see 3.5.3.3).
>
>
> >At some point, either the Client's representative User Agent Server or
the
> >Gateway may decide to terminate the monitoring session. This is achieved
> >by sending an UNSUBSCRIBE request to the correspondent server.  Such a
> >request indicates that the sender intends to close the monitoring session
> >immediately, and, on receipt of the final response from the receiving
> >server, the session is deemed over.
> >
> >Note that unlike the SUBSCRIBE request, which is never sent by a PINT
> >gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User
> >Agent Server to indicate that the monitoring session is closed. (This is
> >analogous to the fact that a gateway never sends an INVITE, although it
> >can send a BYE to indicate that a telephone call has ended.)
> >
> >If the Gateway initiates closure of the monitoring session by sending an
> >UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing for
> >how much longer after this monitoring session is closed it is willing to
> >store information on the service session. This acts as a minimum time
> >within which the Client can send a new SUBSCRIBE message to open another
> >monitoring session; after the time indicated in the Expires: header the
> >Gateway is free to dispose of any record of the service session, so that
> >subsequent SUBSCRIBE requests can be rejected with a "606" response.
> >
> >If the subscription period specified by the Client has expired, then the
> >Gateway may send an immediate UNSUBSCRIBE request to the Client's
> >representative User Agent Server. This ensures that the monitoring
session
> >always completes with a UNSUBSCRIBE/response exchange, and that the
> >representative User Agent Server can avoid maintaining state in certain
> >circumstances.
>
>
> In draft-rosenberg-impp-presence-00.txt, the authors state:
>
> >A SUBSCRIBE request MUST contain a Contact header. This indicates the
> >address(es) (as a SIP URL) to which the client would like to receive
> >notifications. This MUST be be one or more SIP addresses, containing the
> >fully qualified domain names for the host generating the subscription, or
> >the IP address of the host generating the subscription. Other addresses
> >are possible, supporting third party subscriptions. If it contains
> >multiple addresses, notifications will be sent to each address. If no
> >Contact header is present, no notifications will be sent.
>
> Jonathan, instead of the first sentence I propose something like this:
>
> "A SUBSCRIBE request MUST contain a Contact header, unless the SUBSCRIBE
> request is used for Fetching currect state only (see section 5.8)."     OR
>
> "An ordinary SUBSCRIBE request MUST contain a Contact header.  A SUBSCRIBE
> request without a Contact is used for Fetching current state only, and
does
> not cause notifications."
>
> >[When replying to a new subscription,] The 200 OK response SHOULD also
> >contain a copy of the current presence state of the presentity.
>
> >A subscriber may unsubscribe by sending a SUBSCRIBE request with an
> >Expires header of 0. The Contact header indicates the particular address
> >that is being unsubscribed. This MAY be a *, indicating that all Contacts
> >for that particular subscription (as identified by the Call-ID, To, and
> >From) are to be removed. If all Contacts are removed, the PA deletes the
> >subscription.
>
> >Fetching is similar to a subscribing, in that it returns the current
> >presence state. However, no notifications are sent for future changes in
> >the presence state. Rather than inventing a new method for this, it is
> >readily accomplished with a SUBSCRIBE along with an Expires: 0 header and
> >no Contact header. The absence of any Contact header is what
distinguishes
> >it from the similar operation of unsubscribing. The advantage of using
> >SUBSCRIBE is that the server can simply process the request independently
> >of whether its a fetch or longer lived subscription; the authorization
and
> >processing steps are identical. The only difference is whether an actual
> >subscription is instantiated for the user or not.
> >
> >This parallels how fetching of registrations is done in SIP. Note that
> >fetching has no effect on existing subscriptions.
>
>
> thanks,
> -rohan
>
>
>
> _______________________________________________
> SIP mailing list
> [e-mail]
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>




_______________________________________________
SIP mailing list
[e-mail]
http://lists.bell-labs.com/mailman/listinfo/sip