Subject: [SIP] New ID: draft-pis-00.txt April 1, 2001

From: [email-masked]
Date: Sun, 1 Apr 2001 15:45:37 EDT

Internet Engineering Task Force                                   
Internet Draft                                             
draft-pis-00.txt
April 1, 2001
Expires: April 1, 2002

                              Turning SIP into PIS
                (Protocol Independent Sessions)

STATUS OF THIS MEMO  This document is an  April-Fools-Internet-Draft 
and is in full conformance with  all provisions of Section 10 of RFC2026 
and the long tradition of the April Fools Day Internet Draft.  
Internet-Drafts are working documents of the Internet Engineering  Task 
Force (IETF), its areas, and its working groups.  April Fools internet 
drafts are especially reserved for those working groups, drafts, protocols,
industry groups, standards bodies, and so forth that could benefit from some
gentle humor and poking, and perhaps a nugget or two of wisdom.  April Fool's
internet drafts are works of fiction and not to be taken seriously.  Note 
that 
other groups may also distribute working documents as Internet-Drafts.  
Internet-Drafts are draft documents valid for a maximum of six months and may 
be updated, replaced, or obsoleted by other documents at any time.  It is 
inappropriate to use Internet- Drafts as reference material or to cite them 
other than as work in progress.  The list of current Internet-Drafts can be 
accessed at  http://www.ietf.org/ietf/1id-abstracts.txt  The list of 
Internet-Draft Shadow Directories can be accessed at  
http://www.ietf.org/shadow.html. 

Abstract:  This document discusses extensions for the SIP protocol to 
extend it for protocol independent services for a variety of applications 
that are relevant to user agents.

1 Introduction  

The Session Initiation Protocol (SIP) is a general purpose tool 
for the initiation, modification, and termination of sessions. SIP 
is typically used to establish multimedia sessions, such as voice or 
video over IP, but has also been proposed via a recent flurry of 
drafts for use in presence services, as well as adopted by a variety 
of industry flora, such as for use in distributed cable packet 
systems, and proposed for use as the next generation terminal 
protocol for wireless systems  in an unusually massive technical 
specification for UMTS (Universal Mobile Telecommunications 
Service).  Unfortunately for SIP, both of these efforts are apt
to differ significantly from standard SIP.  Telephony extensions led 
by a variety of vendors and international switching conundrums also
must be addressed.  Many earlier protocols, such as H.323 have been 
maligned for attempting to address too many diverse needs, and rightfully 
so, but SIP is endangered by these very efforts and perhaps may go the 
way of H.323.  

An effort to unify both of these diverse needs into a common set and 
extend SIP is necessary...  this is collectively called PIS, or 
Protocol Independent Sessions for SIP (the extra S isn't needed) and 
takes in the needs of user agents of both cable and wireless 
systems.  PIS can also be extended for telephony needs to keep the 
telephony community satiated, and this will be published in a 
subsequent internet draft, PIS-T (pronounced piszt, and often legitimately
describes the state of the telephony community in having their needs 
sufficiently addressed by SIP).

   PIS addresses the following areas of SIP:

      - reliable cleanup of SIP sessions
      - cleanup of bandwidth allocation
      - transaction stalls
      - infrastructure and plumbing
      - application sanitization
      - urgent protocol streaming and session steering 

2  PIS Methods

PIS introduces the following new methods, and a short description 
follows.  PIS focuses on proxies and proxy-clusters and the methods
by which user agents access proxy facilities.

2.1 SEEK:

SEEK is used to determine the availability of a proxy.  It is a 
Protocol violation to initiate a PIS session to an occupied proxy, 
depending on the proxy type.  Seek is usually acknowledged as 
follows:

110 Queued
200 Proxy Available at address
300 No suitable proxy available
301 Closed for cleaning

Applications may timeout for excessive queuing and may result in 
SEEK sessions being sent to different domains.  An optional REQUIRES 
parameter may be used to indicate application preferences, eg.

PIS/1.0 SEEK
To: [email-masked]
From: [email-masked]
Requires: Clean-proxy Flushed-proxy Stall-proxy Paper Sani-Shield

Note that certain elements of the requires field may be refined to 
indicate user preferences:

Eg, 

Requires:  Paper-Soft Paper-WholeRoll Paper-Charman 

Sani-Shield is a local term. Alternatively, the term Wax-gasket, 
But-gasket, Rump-protector, Horse-Collar, or other terms may be 
substituted according to the local custom.  Alternatively, the user 
agent MAY use Paper, or choose to signal the Stand or Hover method 
if appropriate and/or supported by the user agent and/or appropriate 
for the proxy type during session flow or simply risk invoking Sit 
on an unshielded proxy.

PIS/1.0 200 Proxy Available
From: [email-masked]
Info : Resources-low |+ No-Shield |+ No-Paper | Malodor | 
Previous-transaction-not-cleared | Previous-transaction-clearing | 
Overflowed |Plugged | Lock-not-functional | Blue-water | 
Clear-water | Green-Water
Type: Stall | Urinal | Hole | Line-urinal | Tire | 
Side-of-Building | Paris-subway | French-quarter-NOLA | 
Bidet | Commode
Requires:  Payment-token
Forbidden:  Use-of-cellphone, eating
Warning: Turbulence | Rough-Seas | Swells | Uneven-pavement | Grade

Note that Stall-proxy and Paper parameters likely indicate the need 
for another session which is not addressed by the PIS protocol, but 
is included for reference and often goes by the names:  POOP, 
Protocol #2, #2, and other vernacular/jargon that the author 
will not repeat such low-brow terms in the interests of maintaining
the high moral and linguistic (and often cryptic, unintelligible, and 
lofty language often used in many RFCs) standards of the IETF.

The Urgency parameter may also be used to indicate the urgency of the
Transaction.  A user agent which uses the urgency parameter MAY be 
expected to skip the AIM method, and MAY forego certain Requires 
parameters.

PIS/1.0 SEEK
To:  [email-masked]
From:  [email-masked]
Urgency:  Normal | Urgent | Bursting | Too-Late

2.2 AIM: 

AIM is used prior to the establishment of a SIP session, before 
INVITE, to ensure that the PIS session is directed in the 
appropriate proxy.  Such may be used by mobile clients to discover 
their serving CSCF (call state commode function) and be forced to 
go there.
  
Failure to use the AIM method may lead to the session establishment 
failure, or in the jargon, the PIS session ending up on the floor.  

Approximately 50% of all user agents are capable of implementing the 
AIM method. User agents which are capable of implementing AIM SHOULD
do so prior to issuing INVITE.

AIM is typically acknowledged as follows:

165 Flow pending
180 Flowing
183 Flow progress
200 ON TARGET, indicating successful aiming
201 Some packets not on target (should this be an INFO message 
during the INVITE?)

300 Lift seat please
307 Proxy overflow...with REDIRECT
506 Previous transaction not cleared.  FLUSH recommended
507 Clogged 
575 Temporary Failure - inebriated.  3 point stance required.

The following is a typical AIM message:

PIS/1.0 AIM
To: [email-masked]
From: [email-masked]

PIS/1.0 575 Temporary Failure - inebriated.  3 point stance required
Info-text:  Don't be a lush.

2.3 FLUSH:

FLUSH, which SHOULD be implemented by well-behaved agents is used 
after the conclusion of the BYE method in SIP, and is used to ensure 
that all resources have been cleaned up and that any residual matter 
left from the previous session to the proxy are cleaned up and as a 
courtesy to the next user agent, and that the FLUSH procedure is not
 required before AIM, thereby improving overall throughput of the 
proxy.  An optional '160 Swirling' or '161 Drain circleage' 
indication MAY be used to indicate the progress of flushing.  
155 'Tank Filling' MAY also indicate progress.  
A 602 'Overflowed' error MAY be returned if there is congestion and 
insufficient throughput to clean up the residual transaction and 
to warn the application to use a different proxy for subsequent 
transactions and notify the maintenance, although the scope of the 
notification is beyond this protocol, and is a management issue (see 
draft-pis-mib-00.txt).  The dreaded 666 'Backup' or 
667 'Septic Reflux' condition indicate an urgent need for the user 
agent to abandon the proxy and/or proxy cluster.  [Note that PIS 
proxies are 'input' only networks in the normal condition...no media 
output is expected.]  470 'Plugged' may also be used to indicate 
the state of the proxy as well.  404 'No Water' also indicates such 
a condition.  300 Partial Flush is used to indicate an incomplete 
FLUSH, and very well-behaved user agents will issue a subsequent 
FLUSH in response to it.  FLUSH may also be used at any time within 
a given session if so desired.

Successful FLUSH is typically acknowledged by a 200 WOOOSH.  Note 
that some advanced proxies can detect that the user is no longer 
using the proxy, and simply issue a 200 WOOSH on their own without 
an explicit FLUSH request from the user.  Such advanced proxies 
SHOULD also support an interim FLUSH as an user override.  Certain 
special types, such as line-urinal, wall-urinal, and pizwah MAY 
support a continuous or periodic FLUSH method, and the user agent 
is not required to employ the FLUSH method.

FLUSH has the following parameters:

How: Tilt-Lever-handle | Injection-Tilt-Valve | Press-Button | 
Automatic | Plunger | Marine-Plunger-Pump | Return-knob | 
Pail-o-water | Overhead-pull-chain

PIS/1.0 FLUSH TID=1
To: [email-masked]
From:  [email-masked]

And is acknowledged by:

100 INFO TID=1
How:  Marine-plunger-pump

And the user successfully completes the transaction by:

200 OK TID=1

But the proxy may acknowledge with:

404 'No water' 

or if water were available,

160 Swirling and a subsequent ACK.

Three other methods of interest are introduced:

2.4 WASH:

WASH, another optional method, is used by well-behaved polite user 
agents following FLUSH or conclusion of the SIP transaction.

PIS/1.0 WASH
To: [email-masked]
From: [email-masked]

WASH is typically acknowledged as follows:

110 Queued
101 INFO
Water-State:  Hot, Cold, Tepid
Water-Status:  Cold-Available, Hot-Available
Handle-Method: 2-handle, 1-handle, automatic
Soap: Yes | No
Dryer-Type:  Pull-towel | Paper-towel | Dryer
Dryer-State: OK | Not-OK
Recommend: Hand-wring
200 SINK-Available
400, 500, 600 No-Water
400, 500, 600 Sink-not-clean, handle-dirty

2.5 FRESHEN:  

FRESHEN SHOULD be used an automatic or manual maintenance procedure 
in high-traffic, high-capacity proxy clusters, but SHOULD be found 
in any size cluster.  Such may be achieved by the Ozium method, 
Potpourri, Carboline-based-propellant-spray (commercially known as 
LYESOL), Aromatic-candle, any sufficiently strong or pleasant 
smelling substance to mask and/or overpower ambient malodor or the
Strike-Match or Light-Cigarette may be self-implemented by the user, 
although strike-match and light-cigarette are inappropriate under 
airplane-lavatory.  Further, strike-match and light-cigarette may 
pose a risk to the user agent if sufficient combustible gases
(CH4...methane) are present, in which case the permanent 
699 'Explosion' is returned.  FRESHEN MAY be initiated by a user 
agent in response to a SEEK response with a Info: Malodor parameter
in an effort to mitigate the condition.

Example:

PIS/1.0 FRESHEN
To: [email-masked]
From: [email-masked]
How: Strike-Match

PIS/1.0 300 Fail
Info: Reeking-Stench, Ventilation-Not-Adequate, Temperature 110F

Special conditions may be required for certain types of stalls, 
such as Airplane-stall and Vacuum-Flusher-Airplane.  The FLUSH 
method on an airplane that supports Vacuum-Flush MAY achieve the 
equivalent of FRESHEN.  Further input from the airline and airplane 
manufacturing industries is sought for the airplane-stall, 
vacuum-flusher-airplane, as well as proper procedures under dynamic 
conditions, such as turbulence, as well as certain state indicators, 
such as Return-to-Seat, No-Smoking, and the appropriate use of the 
Attendant-Call signal.  [H.248 could be used as the protocol to light 
the appropriate indicators via the NOTI method, or out-of-band aural 
methods are possible.]  [Author's observation:  The FRESHEN method is 
often implemented on airplane-stall via the hanging of coffee bags in 
the lavatory, which explains the unique aroma and quality of airplane 
coffee...ever wonder how airlines keep airfares so low and where 
they're skimping?]

Similarly, input from the maritime industry is sought for the 
specifics of Marine-Toilet (or in jargon: Head) and behaviors under 
dynamic conditions, such as Swells or Rough-Seas, as well as when the 
floating-positive-buoyancy-upon-salt-fresh-brackishwater-vehicle 
(jargon: boat) is in motion or stationary, and whether 
electric-pump-flusher or manual-pump-flusher are required. 

In fact, there are many specialized proxy types associated with 
proxy mobility and proxies in motion (and pose special problems for 
location-enabled services as in appendix 1). Bus, train, and RVs MAY 
have embedded proxies.  Furthermore, the specifics of portable 
proxies, such as Chemical-Toilet, the commercial Port-O-Let, 
Chamber-Pot, Bucket, Bedpan, and User-Instantiated-Proxy (with the 
Dig and Requires: Spade methods), are also a consideration.

[Author's note:  While PIS is intended to be a simple protocol, even 
a simple protocol can be ruined by too many specific implementations 
and/or variants...perhaps the industry should take note in enhancements 
to other protocols.] 

2.6 VOMET:

VOMET is used as a negative response to the COMET method, if so 
implemented.  COMET is an overloaded term, and is used for both 
resource reservation and the presence of abrasive pumice-based 
cleansing agents that MAY damage porcelain surfaces and MAY 
contain bleach or other surfactants that MAY be used in the 
maintenance of a proxy and leaves the proxy sparkling clean.  
[Author's note:  I am reminded by a childhood song: COMET...it 
makes you VOMET...and you turn blue, blue, blue... / So if you 
want to VOMET... / Go out and get some COMET... / so that you can 
VOMET to-day.]

3 Session Reliability and Streaming

It should be noted that the media flow or content of a PIS session 
(or stream) is usually continuous, but occasionally, a PIS session 
may have been terminated too soon and an automatic second session 
follows.  Reliable ordered and high-speed delivery is recommended, 
and SCTP is to be used for the transport of these sessions.  
[Author's observation:  How IP may be different that how UP.]

4 Multicast/Multi-unicast, Scalability, and N-ary Relations

User agents do not implement multicast or multi-unicast as a normal 
biological condition of user agents.  The relationship between a 
user agent and a proxy is typically 1 PIS session to 1 Proxy.  The 
special Line-Urinal Proxy type and Pizwah are capable of handling 
certain multiple user agents simultaneously without protocol 
violation.  Well behaved user agents being serviced by a line-urinal 
or pizwah type will implement the Look-at-the-wall method during 
(note this is also considered good etiquette when being serviced by
a Urinal-Type proxy).

5 Local Implementation/National Protocol Variants 

By no means is PIS a complete protocol.  The use of local signaling 
variants may be required depending on the location of the proxy and 
the user agent when roaming may or may not be capable of 
understanding the proper local protocols or methods.  For example, 
the Paper value might be well served in some locales by Leaves, 
Lira, $1-USD, or Low-Denomination-Paper-Currency, [although this use
 of Paper is not part of PIS but may occur in conjunction with a PIS
session].  Certain user agents may not understand the significance 
of the Bidet or Pizwah type.  Local names for proxies, such as 
commodes, stalls, toilets, crappers, urinals, potties/poddy, loos, 
wc's (

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.