Re: 2nd: [SIP] harmonized SUBSCRIBE/NOTIFY behavior

[Jonathan Rosenberg <[e-mail]>]

I responded on the sip-events list, but there wasn't any comment on my
response.

Anyway, this needs to be resolved. Its a big issue that probably will
take more time than is available during the meeting. I would propose an
informal gather at the bar to discuss. If you are interested in coming
to such a gathering, let me know.

I would also like to propose a similar gathering to talk about
directions for multiparty conferencing, another big issue that needs
discussion in real time, but will take too much time to be done in the
meeting itself.

Of course, notes from both informal gatherings will be made available,
and any agreements arrived at are, as always, subject to wg review and
acceptance/rejection.

-Jonathan R.

Rohan Mahy wrote:
> 
> Hi,
> 
> Would anyone care to comment on this, or should this become a SIP LIST OPEN
> ISSUE?
> 
> thanks,
> -rohan
> 
> At 12:16 PM 7/6/00 , Rohan Mahy wrote:
> 
> >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

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.cs.columbia.edu/~jdrosen         PHONE: [phone]
http://www.dynamicsoft.com


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