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".)

>> 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. 

> http://tools.ietf.org/html/rfc3860
> 
> http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid

Reply via email to