2nd: [SIP] harmonized SUBSCRIBE/NOTIFY behavior

[Rohan Mahy <[e-mail]>]

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