Hadriel, > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hadriel Kaplan > Sent: 01 December 2008 15:44 > To: Elwell, John; sipping > Cc: Cullen Jennings > Subject: Re: I-D > Action:draft-kaplan-sipping-pai-responses-00.txt > > > Maybe I don't understand what your update draft is trying to > accomplish, or maybe I don't understand RFC 3325. They're > written in English, but English is not my native language, so > who knows. [JRE] You surprise me. > > My belief is that your draft is trying to clarify that PAI > can be used in other methods than INVITE, that a trusted UAC > can insert it, and that it can be more and different URI > schemes. It's not actually changing the fundamental > definitions/scope of RFC 3325, right? [JRE] Yes > > So let's start with what RFC 3325 is about. For one, it's an > Informational RFC for private use. For another, it actually > does not say what methods a PAI can be inserted in or not - > it only uses the word "message", and in fact says both > requests and responses. It very clearly says that if a Proxy > trusts a node, then it can believe the information as if it > had authenticated the user itself. Are you suggesting your > draft is going to remove that, or re-define that? For what > purpose? This whole thing is about a private network > deciding what "Trust" means to itself! > > But more importantly, RFC 3325 does not define a particular > *instantiation* of a Spec(T). It gives an *example* of one, > but that's it. If I decide for my network that all my PSTN > Gateways and proxies trust each other, then that is my > specific Spec(T). If you decide for your network that only > proxies have a trust relationship, then that's your Spec(T). > In my network, the PSTN gateways can certainly send back PAI > in responses, because they're implicitly authenticated. In > your network they can't, because they're outside of the trust > domain. And the problem is...? [JRE] Spec(T) applies between trusted nodes. This is not the issue. The issue is when a proxy receives a response from an untrusted node, on what basis can it assert an identity for the UAS. Or how can it authenticate the UAS? > > That's why Keith doesn't need to give you any 3GPP use-case. > It's not germane to the draft. 3GPP is simply one particular > Spec(T). It very well could be a bad one (and I think it has > some holes), but that's the nature of a private-use, > privately-defined Spec(T) model to begin with, which is all > RFC 3325 covers! [JRE] I am just the editor. It is Cullen you have to convince. John _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
