Well, yes.
 
However, as per my email, that's not the only alternative.
 
You could use "user=alice" for authentication in HTTP digest if, for whatever 
reason, you prefer to have users authenticating as themselves instead of using 
the shared appearance. That advantage is that users don't need to know 2 
username/passwords. The disadvantage is that you need more infrastructure in 
the back-end to allow Alice to log in as Boss with her own credential. 
 
I was thinking that both model should be allowed. Like in most SIP client 
today, you can put a different HTTP credential (if required).
Otherwise, it would default to the one used for registering (i.e., the From).
 
So in both cases, there is no 3rd party registration per se (as per the 
definition in 3261).
 
That was my thought


________________________________

        From: Venkatesh [mailto:[email protected]] 
        Sent: Wednesday, July 15, 2009 09:36
        To: Audet, Francois (SC100:3055)
        Cc: Hutton, Andrew; Alan Johnston; [email protected]
        Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: 
Provisioningconsiderations
        
        
        Sure, but it means the secretary is now using HelpDesk (or "boss" in 
the example) credentials to register if you didn't have 3rd party registration 
semantics? 

        Venkatesh
        
        
        On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet <[email protected]> 
wrote:
        

                Yes, of course HelpDesk could be the Boss instead.


________________________________

                        From: Venkatesh [mailto:[email protected]] 
                        Sent: Wednesday, July 15, 2009 08:46
                        To: Hutton, Andrew
                        Cc: Audet, Francois (SC100:3055); Alan Johnston; 
[email protected]
                        Subject: Re: [BLISS] 
draft-ietf-bliss-shared-appearances: Provisioningconsiderations
                        
                        
                        Andrew: 

                        Thanks for pointing it out. I missed the change as 
well. Honestly, one of the main use cases for BLA/SLA was to address a 
boss/secretary scenario. In these cases, the secretary is really monitoring a 
"Boss" extension; so from a "ownership" purpose, the AoR is really that of the 
boss and not a "common" address.

                        Venkatesh
                        
                        
                        On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew 
<[email protected]> wrote:
                        


                                Indeed this getting interesting.
                                
                                In version -02 the REGISTER in section 10.1 
showed a normal 1st party
                                registration by alice but -03 shows a third 
party registration which is
                                a significant change.
                                
                                I must admit I missed the text in -02 which 
stated "Bob and Alice are in
                                an appearance group identified by Alice's AOR. 
Bob REGISTERs using
                                contact sip:[email protected] 
<mailto:sip%[email protected]> " and I should have commented on that
                                earlier.
                                
                                As the draft is about sharing appearances of a 
single AOR then surely
                                third party registration is not necessary as it 
could be that there is
                                simply two helpdesk phones using a single AOR 
and there is no "alice" or
                                "bob" AOR's. So in the simplest case the 
REGISTER would be:
                                
                                  REGISTER sip:registrar.example.com SIP/2.0
                                  Via: SIP/2.0/UDP 
ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
                                  From: <sip:[email protected] 
<mailto:sip%[email protected]> >;tag=CDF9A668-909E2BDD
                                  To: <sip:[email protected] 
<mailto:sip%[email protected]> >
                                  CSeq: 2 REGISTER
                                  Call-ID: d3281184-518783de-cc23d6bb
                                  Contact: <sip:[email protected] 
<mailto:sip%[email protected]> >
                                
                                Regards
                                Andy
                                


                                >-----Original Message-----
                                >From: [email protected] 
[mailto:[email protected]]
                                >On Behalf Of Francois Audet
                                >Sent: 14 July 2009 23:30
                                >To: Alan Johnston
                                >Cc: [email protected]
                                >Subject: [BLISS] 
draft-ietf-bliss-shared-appearances:
                                >Provisioningconsiderations
                                >
                                >
                                >> > Section 9:
                                >> >
                                >> > Delete first paragraph.
                                >> >
                                >> > Clarify the UA also REGISTERs to the AOR. 
Discuss the
                                >> security implications, i.e.,
                                >> > you either use the same shared 
username/password, or you
                                >> use a different username/password
                                >> > for HTTP digest, per user. Perhaps the 
security
                                >> considerations can be described in section 
15.
                                >> >
                                >> >
                                >>
                                >> I added text about authorization for third 
party registrations and
                                >> publication.  A little more text on this 
would be helpful.
                                >
                                >Ah-ah... Now we are getting down to business.
                                >
                                >I am now looking at new section 10.1 on 
registration, and I see that
                                >you are using indeed third-party registration 
(with To=HelpDesk,
                                >From=Alice).
                                >
                                >So, this would be one way to to it.
                                >
                                >Another way would be to NOT use third-party 
registration at all. In
                                >other words, Alice would send a first party 
registration on behalf
                                >of HelpDesk (ie.., To=HelpDesk, From=Alice).
                                >
                                >Wouldn't that work?
                                >
                                >Then there is the whole issue of 
authentication with HTTP-Digest.
                                >I guess one could use username="HelpDesk". In 
this case, the
                                >idea is that
                                >Alice would need to know the credentials for 
HelpDesk.
                                >Another way would be to use username="alice" 
instead (i.e.,
                                >her own credentials).
                                >The decisions on which authentication you use 
would depend on
                                >need of the
                                >administrator.
                                >
                                >Have you tought about this? Am I off based?
                                >_______________________________________________
                                >BLISS mailing list
                                >[email protected]
                                >https://www.ietf.org/mailman/listinfo/bliss
                                >
                                _______________________________________________
                                BLISS mailing list
                                [email protected]
                                https://www.ietf.org/mailman/listinfo/bliss
                                



_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss

Reply via email to