RE: [Sipping-tispan] Requirements 02e

[[e-mail]]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jesske, R
> Sent: Wednesday, September 21, 2005 6:58 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: AW: [Sipping-tispan] Requirements 02e
> 
> 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.

What security mechanism is being referred to here?  This may range from none to some proprietary mechanism that a particular implementation may have.

Is it possible to incorporate proprietary mechanisms into a standard by reference?

Mike

> 
> 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-sipp
> ing-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
> 

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