AW: [Sipping-tispan] Requirements 02e

["Jesske, R" <[e-mail]>]

Rocky,
REQ-TIP1: It should be the identity which the connected user want to sent back to the originating user.

REQ-TIP2: For this identity the same security mechanism as for the from header field shall apply.

Roland  

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Rocky Wang
> Gesendet: Mittwoch, 21. September 2005 09:29
> An: 'Miguel Garcia'
> Cc: [e-mail]
> Betreff: RE: [Sipping-tispan] Requirements 02e
> 
> 
> Hi, Miguel,
> 
>    For REQ-TIP-1, I agree with you and it is the same of ours. But
> previously I misunderstand it that the direct communication means it
> should reach to the same terminal.
> 
>    But for REQ-TIP-3, maybe there are still some security problem.
> Suppose user B set and his terminal returns a subscriber C's 
> URI back to
> the calling party A, then what will happen? It will be 
> possible that the
> user A will be misleaded to make a call to C but he wants to 
> make one to
> user B actually.
> 
> Best Regards,
> Rocky Wang
> 
> -----Original Message-----
> From: Miguel Garcia [mailto:[e-mail]] 
> Sent: 2005?9?21? 14:37
> To: Rocky Wang
> Cc: [e-mail]
> Subject: Re: [Sipping-tispan] Requirements 02e
> 
> 
> Hi Rocky:
> 
> inline discussion.
> 
> Rocky Wang wrote:
> 
> >    But I have some more doubts on TIP:
> >    REQ-TIP-1: In addition to any network asserted identity, 
> it must be
> >               possible for the callee to indicate in a SIP 
> response an
> >               additional identity where he is reachable for future
> >               direct communications.
> >    Does it mean the back identifier must be something like 
> gruu? The 
> > one who answers the call from one endpoint does not always mean the 
> > caller should make a call to this endpoint directly later.
> 
> As far as I understand, there is not a requirement for this to be a 
> GRUU. This is just another URI that would lead to the same 
> person, but 
> not necessarily to the same terminal.
> 
> > 
> >    REQ-TIP-3: The identity mentioned in REQ-TIP-1 is 
> considered an end
> >               user supplied information that is not asserted by the
> >               network.
> >    Does it mean the network equipments just transfer the called 
> > party's identifier provided by the called party endpoint? 
> It must be 
> > also asserted, I think. Or, it will cause some security problem.
> 
> It means that the network does not verify the validity of 
> this URI. It 
> is up to the user to put something meaningful there. This is the 
> requirement.
> 
> BR,
> 
>         Miguel
> 
> > 
> > Regards,
> > Rocky Wang
> >    
> > 
> > -----Original Message-----
> > From: Miguel Garcia [mailto:[e-mail]]
> > Sent: 2005?9?20? 14:46
> > To: Rocky Wang
> > Cc: [e-mail]
> > Subject: Re: [Sipping-tispan] Requirements 02e
> > 
> > 
> > Hi Rocky:
> > 
> > Yes, I think we agreed that this is a missing requirement, 
> but we want
> > to write it down when we have finished the other 
> requirements, because
> 
> > it may happen that the calling part categories requirements 
> help us in
> 
> > creating a proper dependency.
> > 
> > So this is not forgotten, it will be added at a later time.
> > 
> > BR,
> > 
> >       Miguel
> > 
> > Rocky Wang wrote:
> > 
> > 
> >>Hi, Migues,
> >>As I considered, the requirement of overrding ACR service must be
> >>there as a formal requirement. Maybe there are some ways that the 
> >>called AS to get enough information to determine that it 
> can or cannot
> > 
> > 
> >>override the ACR, but there are some cases the simulation 
> service must
> > 
> > 
> >>be overrided, including the case you listed in the 02a 
> version. It can
> > 
> > 
> >>be like this: 1. The originating network shall be able to 
> take enough
> >>calling party's information to the terminating network to help to 
> >>override the callee's ACR service. 2. The terminating 
> network shall be
> > 
> > 
> >>able to override the callee's ACR simulation service if the 
> caller is
> >>authorized to do this based on the caller's information.
> >>
> >>Rocky Wang
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]] On Behalf Of Miguel Garcia
> >>Sent: 2005?9?9? 20:57
> >>To: '[e-mail]'
> >>Subject: [Sipping-tispan] Requirements 02e
> >>
> >>
> >>Hi:
> >>
> >>I have another working copy of the TISPAN requirements, now version
> >>02e:
> >>
> >>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipp
ing-tispan
>>-r
>>equirements-02e.html
>>
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan
> -r
> 
>>equirements-02e.txt
>>
>>And a diff version with respect 02d:
>>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan
>>-r
>>equirements-02d-to-e.html
>>
>>The main changes this time are:
>>
>>- Rewording of the CCBS/CCNR requirements as per our discussion. I
>>have
>>added a few definitions and try to reorder them sequentially, so that 
>>they are a bit easier to understand.
>>- Clarification that the TIP requirements are for an additional (to
> 
> the
> 
>>asserted) identity.
>>- Addition of the Communication Waiting requirements
>>
>>Please feel free to comment, but bear in mind that due to the TISPAN 
>>meeting next week most of the TISPANers will have limited time to 
>>discuss.
>>
>>/Miguel
>>
> 
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan