Re: [Sipping-tispan] Requirements 02e

[Miguel Garcia <[e-mail]>]

Inline discussion

Rocky Wang wrote:

> 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.

Ok, I can add a clarification that there is not a requirement to end up 
in 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.

Shame. As I said, there isn't a requirement for the network to assert 
the additional identity. This has been clarified a few times in the 
past, and remember, I am not the owner of the requirements, just the 
scribe. So from TISPAN point of view, the requirement is as is, and the 
security implications are accepted.

/Miguel
> 
> 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-sipping-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