カフェインとタンニンを含む。ドイツコミッションE（ドイツ連邦保険庁の下部委員会で、ハーブを医薬品として利用する場合の効果と安全性を協議している）にて精神および肉体の疲労に対しての使用が承認されている。一方、熱いマテ茶に限り、食道がんや喉頭がんなどの発がんリスクがあるとの説があり、IARCの発がん性評価では、Group2A（ヒトに対する発癌性がある可能性が高い）に分類されている。また、65℃以上の熱い飲み物自体がGroup2Aに分類されている。ただしマテ茶そのものはGroup3（ヒトに対する発癌性が確認できない）に分類される。一説にはこの発がんリスクは上述のボンビーリャと呼ばれるストローを使った飲用方法に原因があるとされ、高温のままのマテ茶をストローで吸引する行為が咽頭部に影響を与えているので、冷たいものであれば安全であるという見方が一般的である。また、カフェインが含まれているためコーヒーなどと同様に、妊娠中および授乳期の摂取は避けたほうがよいとされる。ボリビアではマテと言う言葉は単にハーブティー全般を指し、必ずしもイェルバ・マテのみから作られていないためその成分には注意が必要である。
アルゼンチン・ウルグアイ・ブラジル南部では伝統的な茶器は、ひょうたんでできている。マテとは、現地の言葉でひょうたんを意味し、マテ茶の名前はこのカップに由来する。ひょうたん以外では牛の角や、パロサントという木で作られたものが一般的である。茶器の表面や補強のために付けられる口金、すわりを良くする為の台座には彫刻・彫金などの意匠が施される場合が多く工芸品的な美しさを持っている。茶器は陶器やガラス製のものも使われるが、多孔質の天然材料製でしばらく使った茶器でないと本来の味は出ないとされる。ボンビーリャの材料は古くは葦などの植物の茎を利用したが、現在は金属（銀・洋銀・ステンレスなど）のものがほとんどである。アルゼンチン・ウルグアイで使われる茶器はひょうたんの実の先端の膨らんだ部分を使い、補強された口は狭くなっているため、ボンビーリャの先の茶漉し部分は細長い。ブラジル南部で使われるそれはひょうたんの実の膨らんだ部分で切ってあり、その部分を口にするため、専用の架台なしでは立てることができない。またパラグアイで使われる茶器は牛角製にしろ木製にしろ口が広い。そのためパラグアイやブラジルで購入したボンビーリャはアルゼンチン製の茶器にはほとんど使えない。
初期のマイクロソフトのオペレーティングシステム（MS-DOSもWindowsも）は、ネットワーク機能が貧弱で、NetBIOS/NetBEUIを主に使っていた。これは階層化されていない、ルーティング不可能なネットワーク機能であり、IBM の NetBIOS をマイクロソフトが実装したものであった。特に当時、マイクロソフトはTCP/IPを完全に無視していた。数々の大学グループ（MIT）や商用ベンダー（サン・マイクロシステムズ他）がMS-DOS用TCP/IPを開発し、ハードウェアに同梱するなどして販売していた。Windows がリリースされると、さらに Windows 向け TCP/IP を提供するベンダーが増えていった。しかし、マイクロソフトは相変わらず機能の貧弱な製品を提供していた。これらベンダーの製品の弱点は、それぞれ独自のAPIを採用していた点である。また、メモリ使用量（当時、640KBもあれば大容量とされていた）や、複数のプロトコルを並行してサポートする方法がない点も問題だった。特に最後の問題点は重要であった。当時のネットワーク環境はベンダー毎に異なり（例えば、DECのDECnet、ノベルのNetware、Banyan Vines、IBM Lan Manager など）、それぞれ違ったプロトコルを使っていた（例えば、ノベルは IPX/SPX、IBM は NetBIOS API ベースのプロトコル、マイクロソフトは NetBEUI Frames Protocol）。従って、ユーザーが複数のネットワークサービスに接続するには、複数のブート構成を用意し、使いたいサービスに合わせて立ち上げ直して、対応するプロトコルを使えるようにする必要があった。さらにプログラミングモデルが統一されていないため、任意のベンダーのTCP/IP実装で動作するネットワークアプリケーションの開発は非常に困難であった。何らかの「標準化」が必要であることは明らかであった。当時既にPCネットワークの分野での標準化はいくつも進められていた。アメリカ空軍の支援で行われた標準化として RFC 1001 と RFC 1002 がある。これは TCP/IP 上の NetBIOS 実装であり、NBT (NetBIOS over TCP/IP) と呼ばれた。次に FTP Software 社が中心となって進められた Crynwr packet driver がある。これは、上述したメモリ使用量の問題をアセンブリ言語で実装することで回避し、ネットワークカードの割り込みを独占しないことで複数プロトコルの同時サポート問題にも対応した。同様の試みとしてノベルのODI (Open Data-Link Interface) やマイクロソフトのNDIS (Network Driver Interface Specification) といったAPIがある。これらはTCP/IPも含めたプロトコルスタックの完全な実装ではない点が重要である。従って、例えば Crynwr の Russ Nelson が開発した QVT や WinQVT はDECのVT220端末エミュレータだが、どちらもアプリケーション内にTCP/IPスタックを持っていた。packet driver と同時に使うことが可能で、例えばノベルのIPX/SPXでNetWareのファイルサーバにアクセスすると同時に、DECのVMSにTCP/IP経由でアクセスすることが可能であった。明らかにこのような環境がこのプロジェクトの目指したものであり、例えばパリのOECDなどでそのような使われ方をしていた。Windows Sockets API を提案したのは JSB Software の Martin Hall であり、1991年10月、CompuServeでの電子掲示板での議論が最初であった。仕様の第1版を編集したのは Martin Hall、Mark Towfiq（Microdyne、後にサン・マイクロシステムズ）、Geoff Arnold（サン・マイクロシステムズ）、Henry Sanders と J Allard（マイクロソフト）らである。著作権や知的所有権について議論があり、IETF を通すとか非営利団体を結成するといった議論がなされた。結局、単純に著作権は5人がそれぞれ所有することとなった。後に J Allard はマイクロソフト社内に大きなオフィスを与えられ、そこで ACK と NACK と名づけたイグアナを飼った。