Hi folks:
   
      I have some questions after reading RFC4916, which descibes a solution of 
ensuring the identity of the UA that sends backward request after a dialog has 
formed. As far as I'm concerned, this specification is a supplement of RFC4474, 
which can only provide the validaty of the UA sending the request. However, 
RFC4916's 2 examples regarding to the its desciption only illustrate how to 
convey connected identity in an assumption that the caller and callee are in 
the same domain (example.com in particular), by using UPDATE messages which 
renew the From field of the sender. So my question is, can this specification 
resolve the authentication of the connected identity regarding to the scenories 
where the caller and callee are in different domains?
  [Considering RFC4474, the authenticator will not be the responsible proxy for 
the request that contains a From field ([EMAIL PROTECTED]) that is different 
from its real identity ([EMAIL PROTECTED]) ]
   
      Another doubt I'm concerning about, is the content of last two paragraphs 
in page 3 of RFC4916, which is said as below:
   
     The provision of the identity of the responder in a response
     (commonly called "response identity") is outside the scope of this
     document.
   
        Note that even if identity were to be conveyed somehow in a
        response, there would in general be difficulty authenticating the
        UAS.  Providing identity in a separate request allows normal
        authentication techniques to be used.
   
   
  I can't understand why it's difficult to authenticate response messages as I 
thought it could be authenticated in a way like the request it responses to(I 
don't know how much different in the process it should be regarding request and 
response) .So what's special for response?
   
  Regards,
  Ma Ji
      

       
---------------------------------
抢注雅虎免费邮箱3.5G容量,20M附件! 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to