[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Sip] Comments on draft-rosenberg-sip-reg-00



Title: RE: [Sip] Comments on draft-rosenberg-sip-reg-00
Hi Sriram,
 
please see my comments inline.
 
 
Best regards,
 
Mark
 

Mark Beckmann                   Siemens AG

ICM MP P PS 4S2
P.O.Box 100702                  phone: +49 (5341) 906 1814
D-38228 Salzgitter              fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com

-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Friday, July 26, 2002 3:04 AM
To: BECKMANN MARK; 'sip@ietf.org'
Subject: RE: [Sip] Comments on draft-rosenberg-sip-reg-00

Hi,

I have a comment and a question.

Comment: Mark - I think there is a fairly big difference between "expired" and "deactivated". When you simply do not re-register your device, your registration goes to state Terminated with a reason of "expired" and when an administrator specifically removes your binding, you go to state Terminated with a reason of "deactivated". Let us suppose I have several devices and have SUBSCRIBEd to their reg event, I would be very interested in finding the difference between a device whose Registration expired due my inactivity and one whose Registration expired due to a deliberate action on the part of the administrator. It does not matter that in both cases I am allowed to re-register.
 
[MB] Agreed. My  initial thought was that "deactivated" could be seen as an "expired" with the only difference that the administrator has reduced the duration for which the registration is valid without explicitely telling the device.

Question: Jonathan/Mark - lets use the example that I have several devices attached to an AoR of 'skp@example.com'.  Their contacts are 'skp@pc.example.com', 'skp@sip_phone.example.com' and 'skp@wireless_dev.example.com'. Now I want to authorize somebody to be able to see my registration state on the 'PC' and 'SIP_phone' but not the 'Wireless_device' how do we achieve this? I think there are some privacy concerns here that we may have skipped over, the fact that some Contact address may be private and I do not want to share information about that, while others are public.
 
[MB]  I agree that there is a privacy issue here, which is probably very similar to the one for presence. Therefore it should be stated that a subscription may be authenticated and authorized, whereby the mechanism for authorization is outside the scope of the reg-event draft. The watcher info package may be used for the reg event to inform the "owner" of the registration about subscriptions.

   Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: BECKMANN MARK [mailto:mark.beckmann@sal.siemens.de]
Sent: Thursday, July 25, 2002 7:43 AM
To: 'sip@ietf.org'
Subject: [Sip] Comments on draft-rosenberg-sip-reg-00
Importance: High


Hi Jonathan,

in your draft on the event package for registrations, you proposed the
following FSM for the contacts registered with an adress of record:
                                                                       
                                                                         
                                 +------+                                
                                 |      | refreshed                      
                                 |      |                                
                                 V      |                                
    +------------+            +------------+            +------------+   
    |            |            |            |            |            |   
    |    Init    |----------->|   Active   |----------->| Terminated |   
    |            |            |            |            |            |   
    +------------+ registered +------------+ expired    +------------+   
                   created                   deactivated                 
                                             probation                   
                                             unregistered                
                                             rejected                    
                                                                         

In section 3.1 it is described that in case an administrator wants a device
to re-authenticate, the registration is terminated and the device is
notified, e.g. by setting the event parameter to "deactivated".

First of all, I can't see a big difference between the two events "expired"
and "deactivated". "Deactivated" seems to be part of the "expired" event. In
both cases the contact may be re-registered. It doesn't seem very important
whether the registration is moved to the terminated state because it has
expired or because it has been deactivated.

Secondly, I think in case an administrator wants a device to
re-authenticate, the registration of the corresponding contact should not
move to the terminated state. Instead, another event (for example
"re-authenticate") similar to the "refresh" event should be introduced. When
this event occurs, the device is notified and the duration for which the
contact remains registered is reduced and if the device fails to
re-register, the registration is moved to the terminated state e.g. via the
"expired" event.

Thus, the FSM would look like:
                                                                         
                                 +------+                                
                                 |      | refreshed                      
                                 |      | re-authenticate

                                 V      |                                
    +------------+            +------------+            +------------+   
    |            |            |            |            |            |   
    |    Init    |----------->|   Active   |----------->| Terminated |   
    |            |            |            |            |            |   
    +------------+ registered +------------+            +------------+   
                   created                   expired              
                                             probation           
                                             unregistered          
                                             rejected              

Best regards,


Mark


Mark Beckmann                   Siemens AG

ICM MP P PS 4S2
P.O.Box 100702                  phone: +49 (5341) 906 1814
D-38228 Salzgitter              fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip