MCP 2026-07-28 Panduan Migrasi: Pelayan Tanpa Keadaan

TL;DR: MCP 2026-07-28 menghapuskan sesi pada peringkat protokol dan jabat tangan inisialisasi wajib. Pasukan produksi perlu mencari kebergantungan sesi tersembunyi, mengguna pakai metadata protokol per permintaan, melaksanakan Multi Round-Trip Requests, mengemas kini polisi gerbang, dan melakukan canary terhadap protokol baharu sebelum menamatkan tingkah laku legasi.

Spesifikasi Model Context Protocol yang dikeluarkan pada 28 July, 2026 memperkenalkan perubahan seni bina terbesar kepada MCP sejak sokongan pengangkutan jauh ditambah.

Protokol kini menggunakan teras permintaan-dan-respons tanpa keadaan. Pertukaran initialize dan notifications/initialized yang diperlukan telah tiada, Mcp-Session-Id telah dibuang, dan setiap permintaan membawa maklumat protokol yang diperlukan untuk memprosesnya.

Keluaran ini juga memperkenalkan Multi Round-Trip Requests, pengepala perutean HTTP, respons senarai yang boleh di-cache, tingkah laku pemberian kuasa yang lebih ketat, rangka kerja sambungan, dan kitar hayat penyahtumpuan rasmi. Lihat pengumuman rasmi keluaran MCP 2026-07-28 dan perubahan lengkap spesifikasi untuk butiran peringkat protokol.

Perubahan ini memudahkan pelayan MCP jauh untuk diskala di belakang infrastruktur HTTP piawai. Ia tidak serta-merta menjadikan aplikasi sedia ada tanpa keadaan.

Pelayan produksi masih boleh bergantung pada ruang kerja dalam memori, perutean sticky, kelayakan terikat sesi, strim jangka panjang, atau interaksi yang dimulakan pelayan. Panduan ini memfokuskan pada mencari dan menggantikan kebergantungan tersebut.

Untuk panduan pelaksanaan yang lebih pengenalan, baca How to Create an MCP Server for Claude Code sebelum memulakan migrasi.

Siapa Perlu Bermigrasi?

Tahap usaha bergantung pada bagaimana MCP digunakan dalam sistem anda.

Pelayan setempat yang tidak mengekalkan keadaan merentas permintaan mungkin hanya memerlukan naik taraf SDK dan ujian keserasian.

Penyebaran jauh yang menggunakan sesi, OAuth, penstriman, atau permintaan yang dimulakan pelayan memerlukan migrasi berperingkat.

Apa yang Berubah dalam MCP 2026-07-28?

1. Audit Pelaksanaan Sedia Ada

Sebelum menaik taraf, cari dalam klien, pelayan, gerbang, dan konfigurasi penyebaran anda untuk andaian protokol lama.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Kemudian jawab soalan berikut:

1. Adakah pelayan menolak panggilan sehingga inisialisasi selesai?
2. Adakah ID sesi memilih pengguna, kelayakan, ruang kerja, atau perbualan?
3. Bolehkah instans pelayan lain meneruskan aliran kerja yang dimulakan oleh yang pertama?
4. Adakah penimbal beban memerlukan kelekatan sesi?
5. Adakah alat melakukan kesan sampingan sebelum meminta pengesahan?
6. Adakah gerbang menghurai badan untuk mengenal pasti kaedah atau alat?
7. Adakah kelayakan OAuth disimpan tanpa pelayan pemberian kuasa yang mengeluarkannya?
8. Adakah klien bergantung pada sambungan semula SSE atau penghantaran semula mesej?
9. Adakah senarai alat atau sumber berbeza mengikut sambungan?
10. Ciri deprecated manakah masih menerima trafik produksi?

Jangan buang Mcp-Session-Id sehingga anda memahami apa yang aplikasi simpan di belakangnya.

Pelayan yang membuang pengepala tetapi mengekalkan keadaan dalam memori setempat mungkin berfungsi semasa pembangunan dan gagal secara berselang apabila permintaan diedarkan merentas pelbagai instans.

2. Gantikan Keadaan Sesi Tersembunyi

MCP 2026-07-28 menghapuskan sesi pada peringkat protokol, bukan keadaan aplikasi.

Keadaan yang diperlukan merentas panggilan harus menggunakan salah satu daripada tiga corak.

Pemegang Eksplisit

Kembalikan pemegang yang dicipta pelayan daripada satu alat dan wajibkan ia dalam panggilan kemudian.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Ruang kerja telah dicipta."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Permintaan kemudian menghantar pemegang sebagai argumen biasa:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

Ini menjadikan kebergantungan itu kelihatan dalam kontrak alat dan membolehkan mana-mana instans pelayan serasi memproses permintaan tersebut.

Stor Bersama

Gunakan pangkalan data, cache teragih, stor objek, atau sistem tugasan tahan lama apabila:

• beberapa pekerja memerlukan keadaan yang sama;
• aliran kerja mesti bertahan selepas but semula;
• keadaan terlalu besar untuk pemegang;
• aliran kerja berlangsung lebih lama daripada satu permintaan;
• tingkah laku transaksional atau sekali guna diperlukan.

requestState Terlindung

MRTR boleh memulangkan nilai requestState legap yang akan digaungkan oleh klien apabila mencuba semula permintaan asal.

Oleh sebab nilai itu melalui klien, lindunginya dengan HMAC atau penyulitan diautentikasi. Ikatkannya pada prinsipal yang diautentikasi, operasi asal, parameter penting, masa luput, dan nonce apabila perlindungan ulangan diperlukan.

Jangan sekali-kali mempercayai nilai requestState yang tidak ditandatangani hanya kerana klien memulangkannya tanpa berubah.

3. Guna Pakai Permintaan Swakandung dan Penemuan

Permintaan MCP moden menyertakan konteks protokol dalam _meta.

Panggilan alat Streamable HTTP boleh kelihatan seperti ini:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "migrasi MCP stateless"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Pelayan yang menyasarkan protokol baharu mesti melaksanakan server/discover, yang mengiklankan versi, keupayaan, dan identiti pelayan yang disokong. Klien boleh memanggilnya sebelum operasi lain atau menggunakannya untuk menentukan sama ada fallback legasi diperlukan.

Baca server/discover documentation rasmi untuk kontrak respons.

Rundingan Versi TypeScript SDK

Naik taraf TypeScript SDK sahaja tidak serta-merta menukar klien kepada protokol baharu.

Klien yang menggunakan SDK v2 mesti memilih secara eksplisit:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

Dalam mod automatik, SDK akan mencuba dengan server/discover dan boleh berundur ke aliran inisialisasi lama apabila ia mencapai pelayan legasi.

Pasukan yang masih menggunakan @modelcontextprotocol/sdk v1 harus terlebih dahulu mengikut panduan migrasi TypeScript SDK v1-ke-v2 rasmi. Pasukan yang sudah menggunakan v2 harus menggunakan panduan sokongan protokol 2026-07-28 yang berasingan.

4. Gantikan Permintaan Dimulakan Pelayan dengan MRTR

Pelaksanaan MCP terdahulu boleh menghantar permintaan seperti elicitation/create, sampling/createMessage, atau roots/list dari pelayan ke klien.

Protokol baharu menggantikan model itu dengan Multi Round-Trip Requests.

Alirannya ialah:

1. Klien menghantar permintaan asal.
2. Pelayan memulangkan resultType: "input_required".
3. Klien mengumpul maklumat atau kelulusan yang diminta.
4. Klien mencuba semula operasi asal menggunakan ID JSON-RPC baharu.
5. Cubaan semula menyertakan inputResponses dan requestState asal.
6. Pelayan menyiapkan permintaan atau memulakan pusingan lain.

Contoh respons:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Padam projek project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Klien mencuba semula operasi asal:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Pelaksanaan MRTR produksi harus mentakrifkan:

• bilangan pusingan maksimum;
• tempoh luput request-state;
• tingkah laku pembatalan dan penolakan;
• pengesahan skema respons;
• semakan pemberian kuasa pada setiap cubaan semula;
• perlindungan ulangan;
• idempotensi untuk kesan sampingan;
• tingkah laku apabila klien tidak menyokong keupayaan yang diminta.

Elakkan menyiapkan pembelian, pemadaman, potongan kredit, atau penulisan luaran sebelum memulangkan input_required.

Gunakan operasi berperingkat atau kunci idempotensi supaya cubaan semula tidak menggandakan tindakan. Lihat spesifikasi MRTR rasmi untuk model interaksi penuh.

5. Kemas Kini Gerbang, Cache, dan Pemberian Kuasa

Perubahan infrastruktur adalah berkait rapat dan harus diuji bersama.

Sahkan Pengepala Perutean MCP

Permintaan POST Streamable HTTP kini menyertakan:

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

Pengepala ini membolehkan gerbang merutekan, mengukur, memberi kuasa, dan mengehadkan kadar trafik tanpa menghurai setiap badan JSON.

Ia boleh menyokong kawalan seperti:

• had kadar khusus alat;
• polisi berasingan untuk kaedah senarai dan pelaksanaan;
• kelompok pekerja khusus untuk alat mahal;
• akses terhad kepada operasi berisiko tinggi;
• metrik kependaman dan ralat mengikut alat;
• peruntukan kos infrastruktur.

Nilai-nilai ini masih dibekalkan oleh klien. Bandingkannya dengan badan JSON-RPC sebelum menerapkan polisi.

Permintaan tidak boleh menuntut alat berisiko rendah dalam Mcp-Name sambil memanggil alat berbeza dalam badan. Ketidakpadanan pengepala dan badan harus ditolak dan direkodkan.

Gunakan Kunci Cache Peka Pemberian Kuasa

Protokol baharu menambah ttlMs dan cacheScope kepada hasil yang boleh di-cache termasuk:

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

Kunci cache biasanya perlu merangkumi:

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

Jangan guna semula entri cache peribadi merentas pengguna atau penyewa hanya kerana TTL belum tamat.

Tertib alat yang deterministik juga penting. Katalog yang stabil mengelakkan cache miss yang tidak perlu dan boleh meningkatkan penggunaan semula cache prompt model apabila definisi alat dimasukkan ke dalam prompt.

Perkukuh Pengendalian OAuth Issuer

Semasa migrasi pemberian kuasa:

• sahkan nilai iss yang dipulangkan terhadap issuer yang direkodkan untuk aliran tersebut;
• kunci kelayakan klien yang disimpan mengikut issuer;
• jangan sekali-kali guna semula kelayakan dengan pelayan pemberi kuasa lain;
• tetapkan application_type yang sesuai semasa DCR;
• sediakan integrasi baharu untuk Client ID Metadata Documents.

Dynamic Client Registration kekal tersedia untuk keserasian ke belakang, tetapi ia deprecated sebagai pendekatan pendaftaran pilihan.

6. Migrasikan Pemberitahuan, Tasks, dan Ciri Deprecated

Laluan pemberitahuan HTTP GET yang lama dan aliran resources/subscribe atau resources/unsubscribe telah digantikan oleh subscriptions/listen.

Klien membuka strim respons POST jangka panjang dan memilih kategori pemberitahuan yang mereka perlukan. Pemberitahuan kemajuan dan log khusus permintaan kekal dilampirkan pada strim respons untuk permintaan yang mereka huraikan.

Untuk penyebaran pelbagai instans, gunakan bas acara bersama apabila pemberitahuan yang dijana pada satu instans pelayan mesti mencapai langganan yang disambungkan kepada instans lain.

Sambungan Tasks

Kerja jangka panjang telah dipindahkan keluar daripada protokol teras eksperimen ke:

io.modelcontextprotocol/tasks

Sambungan ini menggunakan:

• tasks/get untuk peninjauan;
• tasks/update untuk kemas kini klien-ke-pelayan;
• pemegang tugasan tahan lama;
• subscriptions/listen untuk kemas kini opt-in.

Pola tasks/result dan tasks/list yang lama tidak patut dibawa ke pelaksanaan baharu.

Ciri Deprecated

Ciri berikut adalah deprecated:

Fungsi deprecated kekal tersedia sepanjang tempoh penyahtumpuan, tetapi pelaksanaan baharu tidak sepatutnya menggunakannya. Polisi kitar hayat MCP menyediakan tempoh penyahtumpuan minimum dua belas bulan; ia tidak bermakna setiap ciri mempunyai tarikh penyingkiran disahkan yang sama.

Semak daftar ciri deprecated rasmi sebelum menetapkan tarikh persaraan.

7. Laksanakan Migrasi dengan Selamat

Jangan ubah klien, pelayan, gerbang, cache, dan pemberian kuasa dalam satu keluaran tanpa pemerhatian.

Tertib Migrasi yang Disyorkan

1. Senaraikan versi protokol, SDK, sesi, trafik SSE, klien DCR, dan kaedah deprecated.
2. Naik taraf SDK bukan produksi.
3. Tambah server/discover dan perundingan versi.
4. Gantikan kebergantungan sesi tersembunyi.
5. Laksanakan dan selamatkan MRTR.
6. Tambah pengepala perutean yang disahkan dan cache berlingkup.
7. Uji sempadan issuer pemberian kuasa.
8. Lakukan canary protokol moden bersama laluan legasi.
9. Bersarakan tingkah laku lama hanya selepas menilai telemetri.

Keserasian Semasa Canary

Klien moden + pelayan moden
→ Guna MCP 2026-07-28

Klien moden + pelayan legasi
→ Uji dan berundur apabila disokong

Klien legasi + pelayan dwiversi
→ Teruskan pada laluan legasi

Gabungan tidak disokong
→ Pulangkan ralat versi protokol yang jelas

Keluaran spesifikasi MCP baharu bukan suis merentas ekosistem. Klien, pelayan, SDK, dan platform terhos akan bermigrasi pada kelajuan berbeza.

Telemetri untuk Direkod

Permintaan tools/call satu-langkah yang berjaya tidak mencukupi untuk mengukur migrasi. Aliran kerja yang berulang kali tamat masa, meminta input yang tidak perlu, atau menggandakan penulisan luaran masih merupakan kegagalan produksi.

Bagaimana CometAPI Sesuai dalam Seni Bina MCP

MCP tidak menggantikan API model. Kedua-dua lapisan menyelesaikan masalah integrasi yang berbeza.

Seni bina produksi tipikal kelihatan seperti ini:

Aplikasi atau agen
        ↓
Klien dan pelayan MCP
Alat, sumber, kelulusan, tugasan
        ↓
API model bersepadu
GPT, Claude, Gemini, DeepSeek, dan model lain

MCP menyeragamkan cara agen berinteraksi dengan alat dan konteks. Ia tidak menyeragamkan harga model, kelayakan penyedia, titik hujung inferens, atau failover penyedia.

Pemisahan ini menjadi sangat berguna apabila bermigrasi dari keupayaan Sampling yang deprecated. Jika pelayan MCP atau agen yang menggunakannya masih memerlukan inferens model, aplikasi boleh memanggil API model terus tanpa bergantung pada aliran Sampling MCP yang terdahulu.

Bila Gerbang Model Bersepadu Membantu

Gerbang model bersepadu boleh mengurangkan kerja operasi apabila:

• beberapa pelayan MCP memerlukan akses kepada penyedia model berbeza;
• alat berbeza memerlukan model berbeza;
• pasukan mahu menukar model tanpa menulis semula integrasi khusus penyedia;
• kelayakan, penggunaan, dan pengebilan perlu diuruskan secara berpusat;
• akses model harus kekal bebas daripada perubahan pengangkutan MCP.

CometAPI menyediakan titik hujung serasi OpenAI yang boleh digunakan sebagai lapisan akses model di belakang aplikasi MCP. Ini mengekalkan logik penyedia model terasing daripada alat MCP, sumber, dan orkestrasi tugasan.

Sebagai contoh, alat MCP boleh memanggil model melalui klien serasi OpenAI yang sama digunakan di tempat lain dalam aplikasi:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Ringkaskan sumber yang dibekalkan dengan jelas dan padat."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

Pelayan MCP kekal bertanggungjawab untuk kontrak alat, pemberian kuasa, keadaan, dan pengendalian hasil. Gerbang model mengendalikan pemilihan model, akses penyedia, dan respons inferens.

Memisahkan lapisan ini memberikan dua manfaat praktikal:

1. Klien dan pelayan MCP boleh bermigrasi ke protokol baharu tanpa menukar lapisan integrasi model.
2. Penyedia model boleh ditukar tanpa mereka bentuk semula alat MCP atau tingkah laku pengangkutan.

Untuk butiran pelaksanaan lanjut, lihat CometAPI Quickstart, dokumentasi API, dan panduan aplikasi AI berbilang model.

Senarai Semak Migrasi MCP 2026-07-28

Klien

• Naik taraf kepada SDK serasi.
• Aktifkan perundingan versi moden.
• Sokong server/discover.
• Sertakan metadata protokol pada setiap permintaan.
• Tangani resultType.
• Sokong atau tolak secara eksplisit MRTR.
• Gunakan ID JSON-RPC baharu untuk cubaan semula.
• Kekalkan dan kembalikan requestState.
• Sahkan issuer OAuth.
• Simpan kelayakan mengikut issuer.
• Hormati petunjuk cache.
• Sokong subscriptions/listen apabila diperlukan.

Pelayan

• Buang pintu inisialisasi permintaan moden.
• Buang kebergantungan pada Mcp-Session-Id.
• Laksanakan server/discover.
• Gantikan keadaan tersembunyi dengan pemegang atau stor bersama.
• Pulangkan resultType.
• Gantikan permintaan dimulakan pelayan dengan MRTR.
• Lindungi requestState.
• Sahkan semua inputResponses.
• Tambah idempotensi untuk kesan sampingan.
• Pulangkan senarai yang deterministik.
• Terbitkan petunjuk cache yang konservatif.
• Migrasikan kerja jangka panjang ke sambungan Tasks.

Gerbang dan Infrastruktur

• Sahkan pengepala permintaan MCP.
• Bandingkan pengepala dengan badan permintaan.
• Buang perutean sticky yang tidak perlu.
• Uji permintaan merentas pelbagai instans.
• Bahagikan cache mengikut sempadan pemberian kuasa.
• Tambah bas pemberitahuan bersama apabila diperlukan.
• Jejak trafik legasi dan deprecated.
• Kekalkan laluan rollback semasa canary.

Soalan Lazim (FAQ)

Apakah MCP 2026-07-28?

MCP 2026-07-28 ialah spesifikasi Model Context Protocol yang dikeluarkan pada 28 July, 2026. Ia memperkenalkan teras protokol tanpa keadaan, Multi Round-Trip Requests, pengepala perutean HTTP, hasil yang boleh di-cache, perubahan pemberian kuasa, sambungan, dan kitar hayat penyahtumpuan rasmi.

Adakah Mcp-Session-Id dibuang?

Ya. Protokol Streamable HTTP baharu tidak lagi menggunakan Mcp-Session-Id.

Aplikasi masih boleh mengekalkan keadaan melalui pemegang eksplisit, stor bersama, tugasan tahan lama, atau nilai request-state yang dilindungi.

Adakah jabat tangan inisialisasi MCP dibuang?

Ya. Permintaan moden tidak lagi memerlukan pertukaran initialize dan notifications/initialized.

Pelayan mesti melaksanakan server/discover, walaupun klien tidak perlu memanggilnya sebelum setiap operasi.

Adakah MCP tanpa keadaan bermakna alat tidak boleh mengekalkan keadaan?

Tidak. Tanpa keadaan merujuk kepada lapisan protokol.

Alat masih boleh menyimpan keadaan, tetapi pemprosesan permintaan tidak sepatutnya bergantung pada kelekatan pengangkutan tersembunyi atau satu proses pelayan tertentu.

Apakah MRTR?

Multi Round-Trip Requests membolehkan pelayan meminta input klien atau pengguna tambahan tanpa menghantar permintaan yang dimulakan pelayan melalui sambungan dwidireksi yang dibuka berterusan.

Pelayan memulangkan input_required, dan klien mencuba semula operasi asal dengan respons yang diminta.

Adakah HTTP+SSE dibuang serta-merta?

Tidak. Ia deprecated dan bukannya dibuang serta-merta.

Pelayan baharu harus menggunakan Streamable HTTP, manakala sistem sedia ada harus mengukur dan memigrasi trafik HTTP+SSE yang tinggal.

Adakah klien TypeScript SDK v2 menggunakan MCP 2026-07-28 secara automatik?

Tidak. SDK v2 TypeScript memerlukan konfigurasi perundingan versi eksplisit untuk menggunakan protokol moden.

Gunakan perundingan automatik apabila klien mesti berfungsi dengan kedua-dua pelayan moden dan legasi.

Syor Akhir

MCP 2026-07-28 menjadikan infrastruktur MCP jauh lebih mudah untuk diskala, dirutekan, di-cache, dan diperhati. Risiko migrasi utama bukan sekadar pembuangan pengepala atau jabat tangan. Ia adalah keadaan aplikasi tersembunyi dan logik interaksi yang mungkin masih bergantung padanya.

Sebelum menggunakan protokol baharu:

Cari setiap kebergantungan pada inisialisasi dan Mcp-Session-Id.

1. Pindahkan keadaan yang diperlukan ke pemegang eksplisit atau stor bersama.
2. Laksanakan MRTR dengan luput, perlindungan ulangan, dan idempotensi.
3. Sahkan pengepala MCP terhadap badan JSON-RPC.
4. Bahagikan cache mengikut penyewa dan skop pemberian kuasa.
5. Perkukuh pengesahan issuer OAuth.
6. Ukur kaedah deprecated dan trafik pengangkutan legasi.
7. Lakukan canary laluan protokol moden dan legasi sebelum persaraan.

Anggap migrasi sebagai perubahan infrastruktur dan bukan naik taraf SDK rutin.

Sebaik sahaja lapisan MCP tanpa keadaan dan boleh diperhati, kekalkan akses model di belakang antara muka berasingan. Ini membolehkan protokol alat dan lapisan penyedia model berkembang secara bebas.