I take it that you start with 5.3.1 and compare the two IRIs. If the string comparison produces "equal", you're done. If not, it is still possible that two IRIs are equal, after transformation, so you proceed to step 5.3.2, etc. At any step, if you discover equality, you fall off the ladder and declare equality. The steps are set up not to produce false positives, i.e., declaring two IRIs equal when they are not.
First, I think we can restrict ourselves to discussing URIs appearing in specific protocols, such as part of a SIP From URI or an XMPP URI.I do not agree with this. If HELD comes to fruition, we'll be talking about HTTP schemes as well.
'such as' does not preclude other protocols. For HTTP, the notion of using the request URI as an identifier makes little sense since it identifies the target of the query (the "presentity"). The authorization is clearly based on who is asking, not who is being asked. Thus, for HTTP, you would probably need to use the Digest or other identity string, not the request URI. This is an orthogonal issue, however.
--- begin text ---
Common policy MUST use UTF-8 to store domain names in 'id' domain attributes. For non-IDNs, lower-case ASCII SHOULD be used.
(1) If both domain attribute and protocol domain identifier are in UTF-8 and do not begin with xn--, attempt a string comparison. If the string comparison indicates equality, the comparison succeeds and the remaining steps are skipped.
(2) Translate percent-encoding for either string and repeat (1).
(3) Convert both domain strings using the toASCII operation described in RFC 3490. (Naturally, if one of the strings already begins with the ACE prefix xn--, the conversion operation has already been performed.)
(4) Compare the two domain strings for ASCII equality, for each label.
If the conversion fails in step (3), the domains are not equal.
--- end text ----
Does this work?
-andy
_______________________________________________ Simple mailing list Simple at ietf.org https://www1.ietf.org/mailman/listinfo/simple