Issues with your account? Bug us in the Discord!
RFC 1927 - Suggested MIME Types for Associating Documents
E.T
Quote-o-matic
in Zocalo v2.0
[code]Network Working Group C. Rogers
Request for Comments: 1927 ISI
Category: Informational 1 April 1996
Suggested Additional MIME Types for Associating Documents
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
1) New MIME Types: Staple and "Paper" Clip
1) indicates the degree of binding of multipart documents:
stapled documents should stay together on the desktop,
while paper clipped ones should be easily spreadable
2) big paper clips vs small ones; hierarchical assembly
3) big vs small for large documents vs. small ones?
4) warning! the presence of electronic staples or paper clips
may break some programs, particularly those designed to do
high-speed copying!
2) patents on the electronic staple and paper clip
1) use First Virtual to record a charge each time new staples
or paper clips are made.
2) to reduce transmission charges, electronic staples should be
bought in boxes of 5000. Reference: Apple's "bento"
technology?
3) electronic staples should have a standard "size and shape"
so a supply of staples could be used be used by several
programs.
3) recycling electronic staples and paper clips
1) to assure proper accounting, and to detect patent violations
(people making their own electronic staples), it may be
necessary to attach a certificate to each staple or paper
clip.
2) When a file or folder is deleted, a "recycler" program could
look inside for staples or paper clips that could be reused
or recycled.
1) staples could be reycled for a small credit
2) paper clips could be reused.
4) custom-look electronic staples and paper clips
1) when stabled or clipped documents are displayed on the
desktop, there should be some icon or visual indicator to
show the presence of the (possibly removable) staple
or paper clip
2) "color=" and "shape=" attributes in the MIME line should
allow senders to customize the appearance of individual
staples or paper clips.
1) this could have some significance for office filing
systems, for instance: a silver paper clip could
trigger one workflow component, while
a gold paper clip could trigger another.
3) "src=" would allow the specification of a URL of the image to
be shown, for even greater control of appearance.
4) it should be possible to specify 3D modelling of your custom
paper clip, for electronic desktops being viewed through
virtual reality headsets
5) electronic paper clip sculpture
1) instead of discarding or reusing paper clips, it should be
possible to "bend" them and display the resulting sculpture
on the desktop
1) a morphing interface would be suitable
2) linked chains of paper clips
3) each paper clip should keep track of how many times it has
been bent. Above a certain limit, the clip should fail.
6) electronic paper clips as page flags
1) in addition to using electronic paper clips to group related
documents, it should be possible to attach an electronic
paper clip to a single page of a multipage document or
collection of documents. This highlights or draws
attention to the page.
2) it should be possible to include positioning information
with the electronic paper clip, to mark specific paragraphs
or sentences
3) combinations of color, shape, size, position, orientation,
etc. could have special meaning
7) additional safety hazards of electronic paper clips
1) they should not be used on data files which might end up in
the hands of very small children
1) thus, one should consider keeping them in a locked
drawer of the electronic desk on home PCs
2) they should not be attached to documents on floppy disks, as
they may erase portions of the floppy
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Craig Milo Rogers
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 310-822-1511
EMail: rogers@isi.edu
[/code]
:D
Request for Comments: 1927 ISI
Category: Informational 1 April 1996
Suggested Additional MIME Types for Associating Documents
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
1) New MIME Types: Staple and "Paper" Clip
1) indicates the degree of binding of multipart documents:
stapled documents should stay together on the desktop,
while paper clipped ones should be easily spreadable
2) big paper clips vs small ones; hierarchical assembly
3) big vs small for large documents vs. small ones?
4) warning! the presence of electronic staples or paper clips
may break some programs, particularly those designed to do
high-speed copying!
2) patents on the electronic staple and paper clip
1) use First Virtual to record a charge each time new staples
or paper clips are made.
2) to reduce transmission charges, electronic staples should be
bought in boxes of 5000. Reference: Apple's "bento"
technology?
3) electronic staples should have a standard "size and shape"
so a supply of staples could be used be used by several
programs.
3) recycling electronic staples and paper clips
1) to assure proper accounting, and to detect patent violations
(people making their own electronic staples), it may be
necessary to attach a certificate to each staple or paper
clip.
2) When a file or folder is deleted, a "recycler" program could
look inside for staples or paper clips that could be reused
or recycled.
1) staples could be reycled for a small credit
2) paper clips could be reused.
4) custom-look electronic staples and paper clips
1) when stabled or clipped documents are displayed on the
desktop, there should be some icon or visual indicator to
show the presence of the (possibly removable) staple
or paper clip
2) "color=" and "shape=" attributes in the MIME line should
allow senders to customize the appearance of individual
staples or paper clips.
1) this could have some significance for office filing
systems, for instance: a silver paper clip could
trigger one workflow component, while
a gold paper clip could trigger another.
3) "src=" would allow the specification of a URL of the image to
be shown, for even greater control of appearance.
4) it should be possible to specify 3D modelling of your custom
paper clip, for electronic desktops being viewed through
virtual reality headsets
5) electronic paper clip sculpture
1) instead of discarding or reusing paper clips, it should be
possible to "bend" them and display the resulting sculpture
on the desktop
1) a morphing interface would be suitable
2) linked chains of paper clips
3) each paper clip should keep track of how many times it has
been bent. Above a certain limit, the clip should fail.
6) electronic paper clips as page flags
1) in addition to using electronic paper clips to group related
documents, it should be possible to attach an electronic
paper clip to a single page of a multipage document or
collection of documents. This highlights or draws
attention to the page.
2) it should be possible to include positioning information
with the electronic paper clip, to mark specific paragraphs
or sentences
3) combinations of color, shape, size, position, orientation,
etc. could have special meaning
7) additional safety hazards of electronic paper clips
1) they should not be used on data files which might end up in
the hands of very small children
1) thus, one should consider keeping them in a locked
drawer of the electronic desk on home PCs
2) they should not be attached to documents on floppy disks, as
they may erase portions of the floppy
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Craig Milo Rogers
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 310-822-1511
EMail: rogers@isi.edu
[/code]
:D
Comments
1) instead of discarding or reusing paper clips, it should be possible to "bend" them and display the resulting sculpture on the desktop
[/QUOTE]
office catapult ftw! :D
[IMG]http://i128.photobucket.com/albums/p192/parsimonious/final.jpg[/IMG]
[IMG]http://i128.photobucket.com/albums/p192/parsimonious/final2.jpg[/IMG]
:rolleyes:
[code]
[CENTER][B]RFC2549 - IP over Avian Carriers with Quality of Service[/B]
[/CENTER]
Network Working Group D. Waitzman
Request for Comments: 2549 IronBridge Networks
Updates: 1149 1 April 1999
Category: Experimental
IP over Avian Carriers with Quality of Service
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This memo amends [URL="http://www.faqs.org/rfcs/rfc1149.html"]RFC 1149[/URL], "A Standard for the Transmission of IP
Datagrams on Avian Carriers", with Quality of Service information.
This is an experimental, not recommended standard.
Overview and Rational
The following quality of service levels are available: Concorde,
First, Business, and Coach. Concorde class offers expedited data
delivery. One major benefit to using Avian Carriers is that this is
the only networking technology that earns frequent flyer miles, plus
the Concorde and First classes of service earn 50% bonus miles per
packet. Ostriches are an alternate carrier that have much greater
bulk transfer capability but provide slower delivery, and require the
use of bridges between domains.
The service level is indicated on a per-carrier basis by bar-code
markings on the wing. One implementation strategy is for a bar-code
reader to scan each carrier as it enters the router and then enqueue
it in the proper queue, gated to prevent exit until the proper time.
The carriers may sleep while enqueued.
For secure networks, carriers may have classes Prime or Choice.
Prime carriers are self-keying when using public key encryption.
Some distributors have been known to falsely classify Choice carriers
as Prime.
Packets MAY be marked for deletion using RED paint while enqueued.
Weighted fair queueing (WFQ) MAY be implemented using scales, as
shown:
__
_____/-----\ / o\
<____ _____\_/ >--
+-----+ \ / /______/
| 10g | /|:||/
+-----+ /____/|
| 10g | |
+-----+ .. X
===============================
^
|
=========
Carriers in the queue too long may leave log entries, as shown on the
scale.
The following is a plot of traffic shaping, from coop-erative host
sites.
Alt | Plot of Traffic Shaping showing carriers in flight
|
2k | ....................
| . .
| . .
1k | . .
| +---+ +---+
| | A | | B |
| +---+ +---+
|_____________________________________________
Avian carriers normally bypass bridges and tunnels but will seek out
worm hole tunnels. When carrying web traffic, the carriers may
digest the spiders, leaving behind a more compact representation.
The carriers may be confused by mirrors.
Round-robin queueing is not recommended. Robins make for well-tuned
networks but do not support the necessary auto-homing feature.
A BOF was held at the last IETF but only Avian Carriers were allowed
entry, so we don't know the results other than we're sure they think
MPLS is great. Our attempts at attaching labels to the carriers have
been met with resistance.
NATs are not recommended either -- as with many protocols, modifying
the brain-embedded IP addresses is difficult, plus Avian Carriers MAY
eat the NATs.
Encapsulation may be done with saran wrappers. Unintentional
encapsulation in hawks has been known to occur, with decapsulation
being messy and the packets mangled.
Loose source routes are a viable evolutionary alternative enhanced
standards-based MSWindows-compliant technology, but strict source
routes MUST NOT be used, as they are a choke-point.
The ITU has offered the IETF formal alignment with its corresponding
technology, Penguins, but that won't fly.
Multicasting is supported, but requires the implementation of a clone
device. Carriers may be lost if they are based on a tree as it is
being pruned. The carriers propagate via an inheritance tree. The
carriers have an average TTL of 15 years, so their use in expanding
ring searches is limited.
Additional quality of service discussion can be found in a Michelin's
guide.
MIB and Management issues
AvCarrier2 OBJECT-TYPE
SYNTAX SEQUENCE OF DNA
MAX-ACCESS can't-read
STATUS living
DESCRIPTION "Definition of an avian carrier"
::= { life eukaryotes mitochondrial_eukaryotes crown_eukaryotes
metazoa chordata craniata vertebrata gnathostomata
sarcopterygii terrestrial_vertebrates amniota diapsida
archosauromorpha archosauria dinosauria aves neornithes
columbiformes columbidae columba livia }
AvCarrier OBJECT-TYPE
SYNTAX SET OF Cells
MAX-ACCESS not-accessible
STATUS obsolete
DESCRIPTION "Definition of an avian carrier"
::= { life animalia chordata vertebrata aves
columbiformes columbidae columba livia }
PulseRate OBJECT-TYPE
SYNTAX Gauge(0..300)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Pulse rate of carrier, as measured in neck.
Frequent sampling is disruptive to operations."
::= { AvCarrier 1}
The carriers will not line up in lexigraphic order but will
naturally order in a large V shape. Bulk retrieval is possible
using the Powerful Get-Net operator.
Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST Usually.
MUST NOT Usually not.
SHOULD Only when Marketing insists.
MAY Only if it doesn't cost extra.
Security Considerations
There are privacy issues with stool pigeons.
Agoraphobic carriers are very insecure in operation.
Patent Considerations
There is ongoing litigation about which is the prior art: carrier or
egg.
References
Waitzman, D., "A Standard for the Transmission of IP Datagrams on
Avian Carriers", [URL="http://www.faqs.org/rfcs/rfc1149.html"]RFC 1149[/URL], 1 April 1990.
ACKnowledgments
Jim.Carlson.Ibnets.com > Jon.Saperia . ack 32 win 123 (DF)
Ross Callon, Scott Bradner, Charlie Lynn ...
Author's Address
David Waitzman
IronBridge Networks
55 Hayden Ave
Lexington, MA 02421
Phone: (781) 372-8161
EMail: [EMAIL="djw@vineyard.net"]djw@vineyard.net[/EMAIL]
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.[/code]