Subject: [Sipping] Dots, Dashes, Equals, or something else in SIP Service Request-URI's

From: "Eric Burger" <[email-masked]>
Date: Fri, 27 Jul 2001 16:57:46 -0400

RFC 3087, "SIP Service Control", describes the idea of using the SIP
Request-URI to convey context to an application.  This Informational RFC did
not formally specify any particular services, although it did describe a
voice messaging application.  In essence, the RFC introduces the concept of
putting useful context information into the Request-URI.

Although not stated in the text as a convention, all of the examples used
dashes (-) to separate context elements in the URI.

draft-rosenberg-sip-vxml-00.txt, "A SIP Interface to VoiceXML Dialog
Servers", uses dots (.) to separate context elements in the URI.

draft-burger-sipping-msuri-00.txt, "SIP URI Conventions for Media Servers",
proposes to codify using an equal sign (=) to separate the service indicator
from other context elements.  In this case, the service indicator describes
a master context; the following sub-context elements, if any, relate to the
service indicator.  draft-burger-sipping-msuri-00.txt does not address how
to separate such sub-context elements.

How is this for a proposal:
For context elements that are service indicators (e.g., meta-context), they
get listed first in the Request-URI and are separated from sub-context
elements by an equal sign.  Sub-context elements are separated by dots.

Rationale:
The meta-context drives the parsing of the sub-context elements.  For
example, in draft-burger-sipping-netann-00.txt, the meta-context (service
indicator) is derived from the leading "annc=", while sub-contexts, such as
the path of the announcement, follow the equal sign.  This would suggest
depreciating the Example Scheme 1's of RFC 3087.  Rather than using
"sip:[email-masked]", this would indicate
"sip:deposit=[email-masked]".  Again, the "deposit" indicates the meta
service, "sub" indicates subscriber, and "rjs" indicates the subscriber
Robert Sparks.

I do feel strongly that the separator for the meta-context should be
different than the separator for sub-context elements.  If we took the
advise of RFC 3087, then I have to parse the entire Request-URI to figure
out what this INVITE is about.

I don't feel strongly about dots versus dashes for sub-context elements.  In
draft-rosenberg-sip-vxml-00.txt, the sub-contexts are naturally
hierarchical, which leads me to dots, by convention.  Dashes could work
equally as well.

Thoughts?