On 12/8/10 2:39 PM, Ben Campbell wrote: > > On Dec 8, 2010, at 2:16 PM, Peter Saint-Andre wrote: > > [...] > >>> For example, given an input URI of >>> "sip:alice:[email protected];transport=tcp?subject=project%20x&priority=urgent", >>> >>> the client derives the service type "sip" from the scheme, and the >>> domain name "example.net" from the authority component. >> >> Looks good. I love gnarly URIs. :) >> > > See my comment to Jeff. A simpler URI would be good enough, as long > as its got _something_ beyond just the scheme and authority parts. > And we should be careful with transport=tcp lest someone ask why we > are connecting via TLS. How about just "sips:[email protected]"? (the > "sips" scheme both shows that we intend to use TLS, and illustrates > how a user input scheme of "sips" might result in a reference id > scheme of "sip".)
WFM. >>> Also, given an input URI of "im:[email protected]", the derived >>> service type is "sip" (since the "im" scheme is defined as an >>> abstract scheme in the SIP context by [SIP-IM] (RFC 3428)), and >>> the domain name is again "example.net". >> >> Well, the im: and pres: URIs can result in a derived service type >> of "xmpp", too. It depends on what a service has deployed... >> > > If my SIP client derives an XMPP service, it will violate the > principle of least surprise :-) But on reflection, I think the "im" > example may delve to far into the esoteric even for me. Me, too. And I've already noted that the "im" and "pres" haven't been deployed widely, if at all. Striking that sentence seems sensible. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
