On Dec 8, 2010, at 1:44 PM, Peter Saint-Andre wrote: > On 12/8/10 11:34 AM, Ben Campbell wrote:
[...] >> >> As you mention, 4.2.1 says "The inputs used by the client to >> construct its list of reference identifiers might be a URI that a >> user has typed into an interface..." and "The client might need to >> extract the source domain and service type from the input(s) it has >> received." >> >> In the case of SIP (and of HTTP if we pretended it used URI-IDs, that >> input as typed in by a user is likely to contain stuff that has to be >> stripped out of the reference identifier. For example, in SIP, this >> input is very likely to be the AoR of the person you want to call. > > This is what I don't understand. > > Let's say you are sip:[email protected] and I am sip:[email protected]. > Why does my client need to resolve nostrum.com in order to communicate > with you? It seems to me that my client needs to resolve stpeter.im and > then connect to that as my "home" server on the SIP network. My server > then does the work of routing signalling traffic from stpeter.im to your > server at nostrum.com, but my client doesn't communicate directly with > nostrum.com because I'm not registered there. > It could work either way. It's common for me to have a service that I send outbound requests through, but it's not required by the protocol or the architecture so much as it is an artifact of pesky NATs and SBCs. But even if you do connect via your own service, some device in the "stpeter.im" service is going to eventually have to connect to the "nostrum.com" service. It does that based on the original user input of "sip:[email protected]". > (I freely grant that my understanding might be based on email and XMPP, > whereas SIP might have a different architecture.) Even for XMPP and email, something in your service would eventually have to connect to something in my service, based on my JID or email address. HTTP might be a better example. If I enter "https://stpeter.im/index.php/2010/11/17/another-xmpp-wg-update/"; into my browser, it by default attempts to form a TLS connection directly to speter.im. (Too bad HTTP doesn't use URI-IDs, since it would make an easier to understand example than SIP.) > >> i.e. a URI identifying a user. I am suggesting a soup to nuts example >> of how a real world input such as that gets converted to a resulting >> URI reference identity. > > Yes, examples always help. > >> I don't think this is peculiar to SIP, other than due to the fact >> that SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would >> have similar issues of getting from the URI as entered by a user to a >> source identifier in URI form. > > In the case of HTTP, my client (browser) is going to pull out the > "authority" component of the URI: > > http://www.example.com/foobar.html => www.example.com > > But I think we already say that in Section 4.2.1: > > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs (e.g., > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing > attack), then the client might end up communicating with an > unexpected application service. > > See also Section 4.3: > > o For a reference identifier of type URI-ID, the DNS domain name > portion is the "reg-name" part of the "authority" component and > the application type portion is the scheme name matching the > [ABNF] "scheme" rule from [URI] (not including the ':' separator). > As previously mentioned, this document specifies that a URI-ID > always contains an "authority" component whose "host" subcomponent > contains a "reg-name". (Matching only the "reg-name" rule from > [URI] limits verification to DNS domain names, thereby > differentiating a URI-ID from a uniformResourceIdentifier entry > that contains an IP address or a mere host name, or that does not > contain an "authority" component at all.). Furthermore, note that > extraction of the "reg-name" might necessitate normalization of > the URI (as explained in [URI]. As an example, a URI-ID of "sip: > voice.example.edu" would be split into a DNS domain name portion > of "voice.example.edu" and an application type of "sip" (mapping > to an application protocol of SIP as explained in [SIP-CERTS]). Most of that text is specification, not example. The example in 4.3 is trivial in the sense that all that the source URI contained was the scheme and the authority. The implementation basically had to cut out a colon :-) > > However, perhaps we need to say more in Section 4.2.1, including some > examples? I think 4.2.1 says the right things as far as the specification language goes. Perhaps merely expanding the example in 4.3 bullet 4 to u say something along the lines of "A SIP Address of Record of "sip:[email protected]" would yield a DNS domain portion of "voice.example.edu" and an application type of "sip", yielding a URI-ID of "sip:voice.example.net" Alternately, a URI-ID example in 4.2.2 could work, although I realize none of the other examples in that section start with the raw user input. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
