Difference between revisions of "FeatureSpec"
Jump to navigation
Jump to search
RjS-legacy (talk | contribs) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | This page did not attract much contribution. | ||
| + | Please see [http://tools.ietf.org/html/draft-sparks-sip-3261-interop-statement-00|the 3261 interop statement draft] instead. | ||
| + | <pre> | ||
This page and its children are a brainstorming sandbox capturing | This page and its children are a brainstorming sandbox capturing | ||
thinking on the level to characterize the requirements in the | thinking on the level to characterize the requirements in the | ||
| Line 9: | Line 12: | ||
For example, we would rather identify a feature like | For example, we would rather identify a feature like | ||
"A registrar successfully adds a binding against an AOR" rather than | "A registrar successfully adds a binding against an AOR" rather than | ||
| − | "A registrar returns a 200 OK to a REGISTER containing a contact not currently | + | "A registrar returns a 200 OK to a REGISTER containing a contact not currently |
| − | + | in the database and puts that contact int he 200 OK it returns". And we | |
''particularly'' don't want to repeat each of these with the combinitorial | ''particularly'' don't want to repeat each of these with the combinitorial | ||
explosion of characterizing it with each possible knob you can turn ("Over UDP", | explosion of characterizing it with each possible knob you can turn ("Over UDP", | ||
| Line 20: | Line 23: | ||
* A UA placing an invite | * A UA placing an invite | ||
* A proxy forwarding a message | * A proxy forwarding a message | ||
| + | </pre> | ||
Latest revision as of 12:47, 17 May 2009
This page did not attract much contribution. Please see 3261 interop statement draft instead.
This page and its children are a brainstorming sandbox capturing
thinking on the level to characterize the requirements in the
SIP specifications for use in, for example, an IESG interoperability
statement for advancing each document.
We know we don't want to replicate each MUST/SHOULD/MAY, but instead
want to capture "features" that encapsulate groups of those requirements.
For example, we would rather identify a feature like
"A registrar successfully adds a binding against an AOR" rather than
"A registrar returns a 200 OK to a REGISTER containing a contact not currently
in the database and puts that contact int he 200 OK it returns". And we
''particularly'' don't want to repeat each of these with the combinitorial
explosion of characterizing it with each possible knob you can turn ("Over UDP",
"Using DIGEST authentication").
The short term goal will to be to capture a few such statements for
* A registrar
* A registering client
* A UA placing an invite
* A proxy forwarding a message