The UI isn’t for viewing a ticket, but for allwoing RT to know where a ticket is.
But yes, for a queue uri, we’d get /queue/
I was almost about to buy it, but then … not really 
In this case we merely want to construct an URI that should reference a
ticket (or anything else). That’s what we need right here and now. I
can’t think of any needs for it at the moment - but anyway I really think
it would be shortsighted to do it in such a way that it will not be
possible to construct “fsck.com-rt”-URIs that can be used for viewing a
ticket, performing actions with one or several ticket(s), or just
whatever.
With the path construct above, this will break. It’s not easy to
construct an easy to read, consistant and truely unambigious URI that
contains all the wanted data. Parameters are better than a path. So I
would say something like
fsck.com-rt://$domain/instancename?ticket=$ticket
fsck.com-rt://$domain?ticket=$ticket
fsck.com-rt://$domain/instancename?queue=$queue&keyword=$keyword&action=resolve
(etc)
or, if you really dislike ? and &, maybe this is better
fsck.com-rt://$domain/instancename/ticket=$ticket
fsck.com-rt://$domain/instancename/queue=$queue
(etc)
About the relationship between the fsck.com-rt URI and other URIs … the
fsck.com-rt URIs should always be possible to convert to URIs starting
with “mailto” or “http” or maybe even “tcx.se-mysql” based on information
stored in the svc records and/or a configuration file and/or the database
and/or whatever.
Yeah. The problem is that instance names don’t map cleanly to domains.
maybe it should be fsck.com-rt://domain/instancename/ticket/number
Instancename should be optional, I think. Most domains/subdomains have
only one instance running, I’d daresay.
Tobias Brox
aka TobiX
+47 22 925 871