XML-binary Optimized Packaging

1 Introduzione

Questo documento definisce la convenzione Pacchetto Ottimizzato XML-binario (XML-binary Optimized Packaging, XOP), un mezzo più efficiente di serializzare Infoset XML (vedere [XMLInfoSet]) che abbiano certi tipi di contenuto.

Si crea un pacchetto XOP mettendo una serializzazione di un Infoset XML in un formato di pacchetto estensibile (come un MIME Multipart/Related, vedere [RFC 2387]). Poi, si estraggono parti selezionate del suo contenuto che siano dati binari codificati con base64, si ricodificano (ad esempio, il dato è decodificato da base64) e si mettono nel pacchetto. Le posizioni di queste parti selezionate sono marcate nel XML con un elemento speciale che le collega con i dati imballati usando URI.

In molti applicazioni XOP importanti, i dati binari non si devono mai codificare in una forma base64. Se il dato ad includere è già disponibile come una catena binaria octet, allora un'applicazione o altro software che agiscano così possono direttamente copiare questo dato in un pacchetto XOP, preparando allo stesso tempo elementi di collegamento appropriati per essere usati nella parte radice; quando un pacchetto XOP è analizzato i dati binari possono diventare disponibili direttamente per le applicazioni, oppure, se corrisponde, la rappresentazione del carattere binario base64 può computarsi dai dati binari.

Comunque, a livello concettuale, possiamo pensare questi dati binari come codificati con base64 nel Documento XML. Siccome questa forma concettuale può essere necessaria durante alcuni processamenti del Documento XML (ad esempio, per firmare il documento XML), bisogna avere una o due corrispondenze tra Infoset XML e Pacchetti XOP. Perciò, si deve rappresentare concettualmente questi dati binari come si fossero codificati con base64, usando la forma lessicale canonica dello Schema XML base64Binary datatype (vedere [XML Schema Part 2: Datatypes Second Edition] 3.2.16 base64Binary). Nel senso opposto, XOP è capace di ottimizzare soltanto dati Infoset codificati con base64 che siano nella sua forma lessicale canonica.

Soltanto i contenuti dell'elemento possono essere ottimizzati; attributi, caratteri di dati non compatibili con base64, e dati che non siano rappresentati canonicamente con datatype base64Binary non si possono ottimizzare con successo con XOP.

Le altre sezioni di questa specifica sono organizzate così:

La Sezione 2 descrive l´Infoset XOP, che conserva i contenuti e le strutture non ottimizzate dell'Infoset XML originale.
La Sezione 3 specifica il modello di processamento XOP.
La Sezione 4 di questa specifica descrive la forma del Pacchetto XOP.
La Sezione 5 descrive come si identificano i Documenti XOP.
La Sezione 6 esplora le considerazioni di sicurezza dell' uso della convenzione XOP.

1.1 Terminologia

Questa specifica usa la terminologia dell'Infoset XML (vedere [XMLInfoSet]) quando tratta la struttura e i contenuti XML. Questo è soltanto una convenzione che permette specificare chiaramente il comportamento del XOP.

I seguenti termini sono usati in questa specifica:

Infoset XML Originale - Un Infoset XML a ottimizzare.
Contenuto Ottimizzato - Contenuto che è stato rimosso dal Infoset XML.
Infoset XOP - L'Infoset Originale con qualsiasi Contenuto Ottimizzato rimosso e sostituito dagli item informazione dell'elemento xop:Include .
Documento XOP - Una serializzazione dell'Infoset XOP usando una versione XML di qualsiasi livello di raccomandazione W3C.
Pacchetto XOP - Un pacchetto che contiene un Documento XOP e qualsiasi Contenuto Ottimizzato. Come insieme, il pacchetto XOP è una serializzazione alternativa dell'Infoset Originale.
Infoset XML Ricostruito - Un Infoset XML che è stato costruito da parti di un Pacchetto XOP.

1.2 Esempi

L'Esempio 1 mostra un Infoset XML prima del processamento XOP. L'Esempio 2 mostra lo stesso Infoset serializzato usando il formato XOP in un pacchetto MIME Multipart/Related. Il contenuto codificato con base64 degli elementi m:photo e m:sig è stato sostituito da un elemento xop:Include, mentre gli octet binari sono stati serializzati in parti MIME separate. Si prenda nota che questi esempi usano [Assigning Media Types to Binary Data in XML] per identificare i mediatype del contenuto degli elementi m:photo e m:sig. Si noti anche che il dato campione base64 è più piccolo di quello che sarebbe tipico e gli octet binari non si mostrano; di fatto, la forma ottimizzata probabilmente sia abbastanza più piccola dell'originale.

Esempio: Infoset XML prima del processamento XOP (Esempio 1, SOAP)

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope' 
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo 
  xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
      <m:sig 
  xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

Esempio: Infoset XML serializzato come un pacchetto XOP (Esempio 2, SOAP)

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml; 
    charset=UTF-8; 
    type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo 
  xmlmime:contentType='image/png'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/me.png'/></m:photo>
      <m:sig 
  xmlmime:contentType='application/pkcs7-signature'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/my.hsh'/></m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--

L'Esempio 3 mostra un Infoset XML prima del processamento XOP. L'Esempio 4 mostra lo stesso Infoset, serializzato usando il formato XOP in un pacchetto MIME Multipart/Related. Il contenuto codificato con base64 degli elementi m:photo e m:sig è stato sostituito da un elemento xop:Include, mentre gli octet binari sono stati serializzati in parti MIME separate. Si prenda nota del fatto che il dato campione base64 è più piccolo di quello che sarebbe tipico e gli octet binari non si mostrano; di fatto, la forma ottimizzata è probabilmente abbastanza più piccola che quell'originale.

Esempio: Infoset XML prima del processamento XOP (Esempio 3, non-SOAP)

<m:data xmlns:m='http://example.org/stuff'>
  <m:photo>/aWKKapGGyQ=</m:photo>
  <m:sig>Faa7vROi2VQ=</m:sig>
</m:data>

Esempio: Infoset XML serializzato come pacchetto XOP (Esempio 4, non-SOAP)

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    start-info="text/xml"
Content-Description: An XML document with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml; 
    charset=UTF-8; 
    type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<m:data xmlns:m='http://example.org/stuff'>
  <m:photo><xop:Include 
  xmlns:xop='http://www.w3.org/2004/08/xop/include' 
  href='cid:http://example.org/me.png'/></m:photo>
  <m:sig><xop:Include 
  xmlns:xop='http://www.w3.org/2004/08/xop/include' 
  href='cid:http://example.org/my.hsh'/></m:sig>
</m:data>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--

1.3 Convenzioni di Notazione

Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DOVRÀ", "NON DOVRÀ", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "POTREBBE", e "FACOLTATIVO" in questo documento si devono interpretare come descritte in RFC 2119 [RFC 2119].

Questa specifica usa dappertutto una serie di prefissi namespace; sotto vi è un elenco. Si deve capire che la scelta di qualsiasi prefisso namespace è arbitraria e non significativa semanticamente.

Prefissi e Namespace usati in questa specifica.
Prefisso	Namespace
Prefisso	Note
xop	"http://www.w3.org/2004/08/xop/include"
xop	Un documento non-normativo Schema XML [XML Schema Part 1: Structures Second Edition], [XML Schema Part 2: Datatypes Second Edition] per il namespace "http://www.w3.org/2004/08/xop/include" è disponibile presso http://www.w3.org/2004/08/xop/include. Lo Schema XML Schema > attualmente fornisce soltanto la validazione dell'Infoset XML 1.0; perciò, > lo schema potrebbe non essere usabile > con Infoset XOP corrispondenti a versioni posteriori dello XML.
xmlmime	"http://www.w3.org/2004/11/xmlmime"
xmlmime	Il namespace per l'attributo contenuto tipo.
soap	"http://www.w3.org/2003/05/soap-envelope"
soap	Il namespace SOAP 1.2 [SOAP12].
xs	"http://www.w3.org/2001/XMLSchema"
xs	Il namespace dei tipi di dati Schema XML [XML Schema Part 2: Datatypes Second Edition].

Nota Editoriale: HR
Si prenda nota che l´URI "http://www.w3.org/2004/11/xmlmime" non è finale e cambierà per adeguarsi all'evoluzione del documento "Assigning Media Types to Binary Data in XML" .

2 Strutture Infoset XOP

L' XOP opera estraendo il Contenuto Ottimizzato dall'Infoset Originale per creare l'Infoset XOP. In particolare, gli item informazione del carattere derivati degli item informazione dell' elemento a ottimizzarsi sono stati rimossi e sostituiti con un item informazione dell' elemento informazione chiamato xop:Include. L'item informazione dell'elemento xop:Include contiene un item informazione dell'attributo con un collegamento alla parte del Pacchetto XOP che porta una rappresentazione binaria del dato rimosso dall'item informazione dell'elemento originale. I particolari della costruzione e il processamento delle serializzazioni XOP sono forniti in Modello di Processamento 3 XOP.

L' Infoset usato come input per il processamento XOP NON DEVE contenere nessun item informazione dell'elemeno con una proprietà [nome namespace] di "http://www.w3.org/2004/08/xop/include" e una proprietà [nome locale] di Include. Gli infoset che contengano questi item informazione dell'element non potranno essere serializzati usando XOP, giacché durante la ricostruzione dell'infoset un processore non è capace di differenziare tra gli item informazione dell'elemento xop:Include inseriti durante la costruzione del pacchetto XOP e quelli che fanno parte dell'infoset originale.

Le seguenti subsezioni provvedono definizioni formali per contenuto ammissibili negli item informazione dell'elemento e l’ item informazione dell'attributo usati per costruire una serializzazione XOP; il contenuto non specificato esplicitamente non è ammissibile. Uno Schema XML non normativo per le [Extensible Markup Language (XML) 1.0 (Third Edition)] serializzazioni di questi item informazione dell'elemento e item informazione dell'attributo è reperibile presso http://www.w3.org/2004/08/xop/include.

2.1 Item informazione dell'elemento `xop:Include`

L'item informazione dell elemento xop:Include ha:

Un [nome locale] di Include.
Un [nome namespace] di "http://www.w3.org/2004/08/xop/include".
Uno o più item informazione dell' attributo tra le sue [attributi] proprietà come segue:
- Un item informazione dell' attributo href obbligatorio (vedere 2.2 item informazione dell'attributo href).
- Zero o più namespace qualificati item informazione dell'attributo addizionali. Qualsiasi di questi item informazione dell'attributo NON DEVE avere un [nome namespace] di "http://www.w3.org/2004/08/xop/include", NON DEVE cambiare la semantica di processamento dell'item informazione dell' elemento xop:Include e DEVE essere ignorato se non è riconosciuto.
Zero o più namespace qualificati item informazione dell'elemento nella sua proprietà [derivata]. Qualsiasi di questi item informazione dell'elemento NON DEVE avere un [nome namespace] di "http://www.w3.org/2004/08/xop/include", NON DEVE cambiare la semantica di processamento dell'item informazione dell'elemento xop:Include e DEVE essere ignorato se non è riconosciuto.

2.2 Item informazione dell'elemento `href`

L'item informazione dell'attributo href ha:

Un [nome locale] di href.
Un [nome namespace] vuoto.
Un [valore normalizzato] che è una rappresentazione di un' URI (vedere [RFC 2396] con la riforma della [RFC 2732]) che fa riferimento alla parte del pacchetto che contiene i dati logicamente inclusi nel [elemento padrone] (ad esempio, l'item informazione dell'elemento xop:Include). Il [valore normalizzato] DEVE essere un URI valido per cid: schema URI (vedere [RFC 2392]). Inoltre, il [valore normalizzato] DEVE essere una forma lessicale valida dello Schema XML datatype xs:anyURI (vedere [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).
Un [elemento padrone] che è l'item informazione dell'elemento xop:Include che contiene l'tem informazione dell'attributo.

3 Modello di Processamento XOP

Questa sezione descrive il modello di processamento per creare Pacchetti XOP e interpretare Pacchetti XOP. A meno che si affermi un'altra cosa, il risultato di questo processamento DEVE essere semanticamente equivalente a eseguire i passi specificati separatamente e nell'ordine dato.

3.1 Creare Pacchetti XOP

Per creare un Pacchetto a XOP da un Infoset XML Originale:

Assicurarsi che l'Infoset XML Originale non abbia item informazione dell'elemento con un [nome namespace] di "http://www.w3.org/2004/08/xop/include" e un [nome locale] di Include. Come abbiamo visto in 2 Strutture XOP Infoset, gli Infoset XML con questi item informazione dell'elemento non possono essere rappresentati usando XOP.
Creare un pacchetto vuoto.
Identificare dentro l`Infoset XML Originale gli item informazione dell'elemento che devano essere ottimizzati. Per essere ottimizzati, i caratteri che includano il [derivato] dell'item informazione dell'elemento DEVONO essere nella forma canonica di xs:base64Binary (vedere [XML Schema Part 2: Datatypes Second Edition]3.2.16 base64Binary) e NON DEVONO contenere nessun carattere whitespace, prima, insieme o dopo i contenuti non-whitespace.
Creare un Infoset XOP che sia una copia dell'Infoset XML Originale, ma con i [derivati] di ogni item informazione dell'elemento identificati nel passo previo sostituiti con un item informazione dell'elemento xop:Include (vedere 2.1 item informazione dell'elemento xop:Include) costruito così:
1. Trasformare i caratteri sostituiti in dati binari processandoli come dati codificati con base64.
2. Serializzare i dati binari in una nuova parte del pacchetto, con metadata appropriati corrispondenti al [valore normalizzato] dell'item informazione dell'attributo href dell'item informazione dell'elemento xop:Include (vedere 2.2 item informazione dell'attributo href).
3. Se l'item informazione dell'elemento ottimizzato (ad esempio, l´ [antenato] del appena inserito item informazione dell'elemento xop:Include ) ha un item informazione dell'attributo xmlmime:contentType il suo valore DEVE essere convenientemente riflesso nei metadata della parte.
Serializzare l'Infoset XOP risultante nel pacchetto usando una versione XML di qualsiasi livello di raccomandazione W3C (per esempio, [Extensible Markup Language (XML) 1.0 (Third Edition)], [Extensible Markup Language (XML) 1.1]) e identificarlo come la parte radice secondo la convenzione del meccanismo di pacchetto, etichettandolo con l'applicazione/xop+xml media type, come descritto in 5 Identificare Documenti XOP.

Si POSSONO aggiungere parti addizionali al pacchetto per soddisfare i requisiti specifici dell'applicazione. Altri metadata di contenuto specifico POSSONO riflettersi nel pacchetto metadata come appropriati.

Se non è possibile codificare con successo il contenuto nel pacchetto XOP, le realizzazioni DEVONO comportarsi come se quella porzione dell'Infoset XML Originale non è stata nominata per l'ottimizzazione.

3.2 Interpretare i Pacchetti XOP

Questa sezione specifica i mezzi con cui l`Infoset XML Originale può essere ricostruito da un Pacchetto XOP che sia stato preparato secondo le regole stabilite in 3.1 Creare Pacchetti XOP.

Nota: convenzioni o errori che rapportino meccanismi a usarsi nei pacchetti di processamento che erroneamente significhino Pacchetti XOP sono oltre lo scopo di questa specifica.

Per creare un Infoset XML ricostituito da un Pacchetto XOP:

Costruire un Infoset XML analizzando la parte radice del pacchetto come un documento XML. Il documento DEVE essere analizzato secondo il livello della raccomandazione XML identificato dalla dichiarazione XML del documento. Se non vi è nessuna dichiarazione XML, allora il documento DEVE essere analizzato per [Extensible Markup Language (XML) 1.0 (Third Edition)].
Usare quello Infoset XML, per ogni item informazione dell'elemento, E, che ha, come unico membro della sua proprietà [derivato], un item informazione dell'elemento xop:Include (come definito in 2.1 item informazione dell'elemento xop:Include):
1. Localizzare la parte del pacchetto corrispondente al URI nell'item informazione dell'attributo href del item informazione dell'elemento xop:Include (per esempio, corrispondente al URI codificato nel [valore normalizzato] del item informazione dell'attributo).
2. Sostituire l'item informazione dell'elemento xop:Include che appare nella proprietà [derivato] di E con degli item carattere informazione che rappresentino la codifica base64 canonica dell'entità corpo della parte pacchetto identificata (per esempio, sostituire efficientemente l'item informazione dell'elemento xop:Include con i dati ricostruiti dalla parte del pacchetto).

4 Pacchetti XOP

XOP è capace di usare una varietà di meccanismi sottostanti di pacchetto. Questi meccanismi di pacchetto DEVONO essere capaci di rappresentare, con una fedeltà completa, tutte le parti create secondo il 3 Modello di processamento XOP (vedere 3.1 Creare Pacchetti XOP), e DEVONO essere usati di maniera che provvedano mezzi di designare una parte radice distinta (main, primary etc.).

La seguente subsezione specifica normativamente come si usa un meccanismo particolare di pacchetto MIME Multipart/Related, ma non preclude l'uso di altri meccanismi di pacchetto con la convenzione XOP.

4.1 Pacchetti XOP MIME Multipart/Related

Questa sezione descrive come si usa il pacchetto MIME Multipart/Related (come specificato in [RFC 2387]) con XOP.

La parte radice MIME è una parte radice del pacchetto XOP, DEVE avere una serializzazione dell'infoset XOP usando una versione XML di qualsiasi livello della raccomandazione W3C (ad esempio, [Extensible Markup Language (XML) 1.0 (Third Edition)], [Extensible Markup Language (XML) 1.1]), e DEVE essere identificata con un media type di "applicazione/xop+xml" (come si definisce sotto). Il parametro "start-info" del media type del pacchetto DEVE contenere il contenuto tipo associato con la serializzazione di contenuti XML. (ad esempio, conterrà lo stesso valore come parametro "tipo" della parte radice).

Salvo per lo scopo di determinare la parte radice MIME, come si specifica in [RFC 2387], l'ordine delle parti MIME NON DEVE essere considerato significante per il processamento XOP o per la costruzione dell'infoset XOP.

La parte metadata è riflessa nelle zone testata MIME. Specificamente, l'URI usato nel valore di un item informazione dell'attributo href di un item informazione dell'elemento xop:Include contiene un URI che usa il 'cid:' schema (vedere [RFC 2392]), perciò la corrispondente parte MIME DEVE avere una zona testata Contenuto-ID (vedere [RFC 2387] con il corrisponde valore-zona.

Inoltre, se viene trovato un item informazione dell'attributo xmlmime:contentType (come si descrive in 3 Modello di Processamento XOP), DOVRÀ essere riflesso nel valore di zona della testata MIME Contenuto-Type.

5 Identificare Documenti XOP

I Documenti XOP, quando si usano come sistemi similari a MIME, si identificano con il media type "applicazione/xop+xml", con il parametro richiesto "type" portante l'originale contenuto tipo associato della serializzazione XML. Quando il parametro tipo contiene caratteri riservati deve essere appropriatamente citato e scappato.

Per esempio, un pacchetto XOP che usa un pacchetto MIME multipart/related per serializzare un messaggio SOAP 1.2 [SOAP Version 1.2 Part 1: Messaging Framework] con un parametro d'azione di "http://www.example.net/foo" etichetterebbe il pacchetto con il mediatype "multipart/related", e la parte radice con il media type "applicazione/xop+xml" insieme al parametro tipo che contiene "application/soap+xml;action=\"http://www.example.net/foo\"".

5.1 Registrazione

nome MIME media type:

applicazione

nome MIME subtype:

xop+xml

Parametri richiesti:

type: Questo parametro porta il contenuto tipo associato con la serializzazione XML dell'infoset XOP, includendo i parametri approppriati.

Parametri Facoltativi:

charset: Questo parametro ha identica semantica che il parametro charset del media type "applicazione/xml" come si specifica in RFC 3023 [RFC3023].

Considerazioni di Codifica:

Uguali a quelle della "applicazione/xml" descritte in RFC 3023 [RFC3023], sezione 3.2.

Considerazioni di Sicurezza:

Accanto alle considerazione specifiche dell'applicazione, XOP ha le stesse considerazioni di sicurezza descritte in RFC3023 [RFC3023], sezione 10.

Considerazioni d'Interoperabilità:

Non ci sono problemi conosciuti d'interoperabilità.

Specifica Pubblicata:

Questo documento

Applicazioni che usino questo media type:

Non ci sono attualmente applicazioni che usino questo media type.

Informazione Addizionale:

Estensione di File:: XOP
Identificatori di frammento:: Uguale a quello dell' "applicazione/xml" come descritta in RFC 3023 [RFC3023], sezione 5.
Base URI:: Come si specifica in RFC 3023 [RFC3023], sezione 6.
Codice File Type Macintosh:: TEXT

Nome ed email della persona cui rivolgersi per altre informazioni:

Mark Nottingham <mnot@pobox.com>

Uso proposto:

COMMON

Controllore Autore/Cambiamento:

La specifica XOP è un prodotto di lavoro dello XML Protocol Working Group del World Wide Web Consortium. Il W3C ha controllo di cambio su questa specifica.

6 Considerazioni di Sicurezza

6.1 Integrità del Pacchetto XOP

L`integrità degli Infoset ottimizzati usando XOP può avere bisogno di essere assicurata. Siccome i pacchetti XOP si possono trasformare per recuperare questi Infosets (vedere 3.2 Interpretare i Pacchetti XOP), è possibile usare le tecniche attuali di Firma Digitale XML per proteggerli. Comunque, si deve sapere che una firma sull'Infoset non lo protegge necessariamente contro modificazioni di altri aspetti del pacchetto XOP; per esempio, un infoset di controllo di firma può non essere protezione contro un riordinamento delle parti che non siano radice.

Nel futuro un algoritmo trasformatore che si usi con la Firma XML potrebbe fornire un modello di processamento più efficiente in cui gli octect crudi si possano compendiare direttamente.

6.2 Riservatezza del Pacchetto XOP

A volte ci sarà bisogno di assicurare la riservatezza dei Pacchetti XOP. Siccome i pacchetti si possono trasforme in Set d'Informazione XML, le tecniche attuali che permette lo XML Encryption (vedere [XML Encryption Syntax and Processing]) si possono usare per proteggere questi pacchetti. Si può encriptare qualsiasi parte del pacchetto, sia che includa o non includa caratteri base64. L'item informazione dell'elemento CipherData risultante può essere ottimizzato perché il contenuto di questo item informazione dell'elemento sono caratteri base64.

Nel futuro un algoritmo di trasformazione per essere usato con XML Encryption potrebbe fornire un modello di processamento più efficiente in cui gli octet crudi siano direttamente encriptati.

A Relazioni con altre specifiche

Quest' appendice compendia le dipendenze del XOP rispetto alle specifiche implicite, la natura dei payload appropriati per XOP e i mezzi con cui estendere il XOP.

A.1 Dipendenze

La convenzione XOP è stata costruita sulla base di una serie di specifiche implicite. Queste sono:

XML (e.g., [Extensible Markup Language (XML) 1.0 (Third Edition)], [Extensible Markup Language (XML) 1.1]) - Il Documento XOP è codificato usando una versione XML di qualsiasi livello di raccomandazione W3C (vedere 3.1 Creare Pacchetti XOP). I formati che usino XOP DEVONO identificare le versioni of XML che permettano codificare l'Infoset XOP. XOP non obbliga all'uso di meccanismi definiti da XML, includendo quelli che esplicitamente permettono estensioni, né obbliga all'uso di specifiche implicite.
Namespaces in XML (e.g., [Namespaces in XML], [Namespaces in XML 1.1]) - Il Documento XOP usa le versioni di Namespace in XML di qualsiasi livello di raccomandazione W3C che siano compatibili con le versioni XML usate. I formati che usino XOP DEVONO identificare le versioni di Namespaces in XML che permettano codificare l'Infoset XOP. XOP non obbliga all'uso di nessun meccanismo definito dai Namespaces in XML, includendo quelli che esplicitamente permettono estensioni, né obbliga all'uso di specifiche implicite.
Uniform Resource Identifiers (vedere [RFC 2396]) - IL Documento XOP usa URI per localizzare parti nel pacchetto XOP (vedere 2.2 item informazione dell'attributo href. XOP non obbliga all'uso di nessun meccanismo definito da URI, includendo quelli che esplicitamente permettono estensioni, né obbliga all'uso di specifiche implicite.
Meccanismo di Pacchetto - XOP richiede l'uso di un meccanismo di pacchetto che adempia i requisiti di 4 Pacchetti XOP. Uno di questi meccanismi DEVE essere in uso, ma il XOP non richiede un meccanismo specifico, i formati che usino XOP DEVONO identificare almeno uno di questi meccanismi che permettano creare un Pacchetto XOP, e DEVONO specificare come ogni meccanismo permesso si deve usare per costruire il pacchetto XOP.

Il rapporto tra uno di questi meccanismi e il XOP, il Contenuto-Tipo MIME Multipart/Related, è specificato in 4.1 Pacchetti XOP MIME Multipart/Related.

A.2 Payload

Il payload di un Pacchetto XOP è un'Infoset XML. XOP costringe la serie di caratteri ammissibili nel payload a quelli contenuti nella produzione "Char" di una versione XML di livello raccomandazione W3C. Inoltre, l'Infoset XML originale non può contenere un item informazione dell'elemento con un [nome locale] di Include e un [nome namespace] di "http://www.w3.org/2004/08/xop/include". Finalmente, le parti del payload che siano nominate per l'ottimizzazione in XOP DEVONO essere dati codificati con base64 nella forma lessicale canonica dello Schema XML Schema base64Binary datatype (vedere [XML Schema Part 2: Datatypes Second Edition] 3.2.16 base64Binary).

A.3 Extension

I Documenti XOP permettono estensione all'elemento xop:Include mentre non cambino la propria semantica. I cambiamenti alla semantica DEVONO essere identificati con un nuovo namespace URI (ad esempio, DEVONO definire un nuovo item informazione dell'elemento Include in altro namespace).

L'estensibilità delle specifiche implicite a XOP non è costretta dall'uso in XOP.

A.4 Requisiti

Questo documento insieme a [SOAP Message Transmission Optimization Mechanism] e [SOAP Representation Header] è stato prodotto in congiunzione con lo sviluppo dei requisiti concretati nel documento [SOAP Optimized Serialization Use Cases and Requirements].

B Riferimenti

B.1 Riferimenti Normativi

Extensible Markup Language (XML) 1.0 (Third Edition): Extensible Markup Language (XML) 1.0 (Third Edition), Jean Paoli, Eve Maler, Tim Bray, e altri, Curatori. World Wide Web Consortium, 04 February 2004. Questa versione è http://www.w3.org/TR/2004/REC-xml-20040204. L'ultima versione è disponibile presso http://www.w3.org/TR/REC-xml.
Extensible Markup Language (XML) 1.1: Extensible Markup Language (XML) 1.1, John Cowan, C. M. Sperberg-McQueen, François Yergeau, e altri, Curatori. World Wide Web Consortium, 04 February 2004. Questa versione è http://www.w3.org/TR/2004/REC-xml11-20040204/. L'ultima versione è disponibile presso http://www.w3.org/TR/xml11/.
SOAP Message Transmission Optimization Mechanism: SOAP Message Transmission Optimization Mechanism, Hervé Ruellan, Noah Mendelsohn, Martin Gudgin, e Mark Nottingham, Curatori. World Wide Web Consortium, 25 January 2005. Questa versione è http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. L'ultima versione è disponibile presso http://www.w3.org/TR/soap12-mtom/.
Resource Representation SOAP Header Block: Resource Representation SOAP Header Block, Martin Gudgin, Yves Lafon, e Anish Karmarkar, Curatori. World Wide Web Consortium, 25 January 2005. Questa versione è http://www.w3.org/TR/2005/REC-soap12-rep-20050125/. L'ultima versione è disponibile presso http://www.w3.org/TR/soap12-rep/.
SOAP Optimized Serialization Use Cases and Requirements: SOAP Optimized Serialization Use Cases and Requirements, Tony Graham, Mark Jones, e Anish Karmarkar, Curatori. World Wide Web Consortium, 08 June 2004. Questa versione è http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/. L'ultima versione è disponibile presso http://www.w3.org/TR/soap12-os-ucr/.
Namespaces in XML: Namespaces in XML, Andrew Layman, Dave Hollander, e Tim Bray, Curatori. World Wide Web Consortium, 14 January 1999. Questa versione è http://www.w3.org/TR/1999/REC-xml-names-19990114. L'ultima versione è disponibile presso http://www.w3.org/TR/REC-xml-names.
Namespaces in XML 1.1: Namespaces in XML 1.1, Richard Tobin, Andrew Layman, Tim Bray, e Dave Hollander, Curatori. World Wide Web Consortium, 04 Febuary 2004. Questa versione è http://www.w3.org/TR/2004/REC-xml-names11-20040204. L'ultima versione è disponibile presso http://www.w3.org/TR/xml-names11/.
XML Information Set (Second Edition): XML Information Set (Second Edition), Richard Tobin e John Cowan, Curatori. World Wide Web Consortium, 04 Feb 2004. Questa versione è http://www.w3.org/TR/2004/REC-xml-infoset-20040204. L'ultima versione è disponibile presso http://www.w3.org/TR/xml-infoset.
XML Schema Part 1: Structures Second Edition: XML Schema Part 1: Structures Second Edition, David Beech, Murray Maloney, Henry S. Thompson, e Noah Mendelsohn, Curatori. World Wide Web Consortium, 28 October 2004. Questa versione è http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. L'ultima versione è disponibile presso http://www.w3.org/TR/xmlschema-1/.
XML Schema Part 2: Datatypes Second Edition: XML Schema Part 2: Datatypes Second Edition, Ashok Malhotra e Paul V. Biron, Curatori. World Wide Web Consortium, 28 October 2004. Questa versione è http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. L'ultima versione è disponibile presso http://www.w3.org/TR/xmlschema-2/.
Assigning Media Types to Binary Data in XML: Assigning Media Types to Binary Data in XML, Ümit Yalçınalp e Anish Karmarkar, Curatori. World Wide Web Consortium, 02 November 2004. Questa versione è http://www.w3.org/TR/2004/WD-xml-media-types-20041102. L' ultima versione è disponibile presso http://www.w3.org/TR/xml-media-types.
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Editor. IETF, March 1997. Questa RFC è disponibile presso http://www.ietf.org/rfc/rfc2119.txt.
RFC 2387: The MIME Multipart/Related Content-type, E. Levinson, Editor. IETF, August 1998. Questa RFC è disponibile presso http://www.ietf.org/rfc/rfc2387.txt.
RFC 2557: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), J. Palme, A. Hopmann and N. Shelness, Curatori. IETF, March 1999. Questa RFC è disponibile presso http://www.ietf.org/rfc/rfc2557.txt.
RFC 2392: Content-ID and Message-ID Uniform Resource Locators, E. Levinson, Editor. IETF, August 1998. Questa RFC è disponibile presso http://www.ietf.org/rfc/rfc2392.txt.
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding e L. Masinter, Curatori. IETF, August 1998. Questa RFC è disponibile presso http://www.ietf.org/rfc/rfc2396.txt.
RFC 2732: Format for Literal IPv6 Addresses in URL's, R. Hinden, B. Carpenter e L. Masinter, Curatori. IETF, December 1999. Questa RFC è disponibile presso http://www.ietf.org/rfc/rfc2732.txt.

B.2 Riferimenti Informativi

Canonical XML Version 1.0: Canonical XML Version 1.0, John Boyer, Editor. World Wide Web Consortium, 15 March 2001. Questa versione è http://www.w3.org/TR/2001/REC-xml-c14n-20010315. L'ultima versione è disponibile presso http://www.w3.org/TR/xml-c14n.
Exclusive XML Canonicalization Version 1.0: Exclusive XML Canonicalization Version 1.0, Joseph Reagle, Donald E. Eastlake 3rd, e John Boyer, Curatori. World Wide Web Consortium, 18 July 2002. Questa versione è http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/. L'ultima versione è disponibile presso http://www.w3.org/TR/xml-exc-c14n.
XML Encryption Syntax and Processing: XML Encryption Syntax and Processing, Joseph Reagle e Donald Eastlake, Curatori. World Wide Web Consortium, 10 Dicembre 2002. Questa versione è http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/. L'ultima versione è disponibile presso http://www.w3.org/TR/xmlenc-core/.
SOAP Version 1.2 Part 1: Messaging Framework: SOAP Version 1.2 Part 1: Messaging Framework, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, e altri, Curatori. World Wide Web Consortium, 24 June 2003. Questa versione è http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. L'ultima versione è disponibile presso http://www.w3.org/TR/soap12-part1/.
SOAP Version 1.2 Part 2: Adjuncts: SOAP Version 1.2 Part 2: Adjuncts, Henrik Frystyk Nielsen, Noah Mendelsohn, Jean-Jacques Moreau, e altri, Curatori. World Wide Web Consortium, 24 June 2003. Questa versione è http://www.w3.org/TR/2003/REC-soap12-part2-20030624/. L'ultima versione è disponibile presso http://www.w3.org/TR/soap12-part2/.

C Riconoscimenti (Non-Normative)

Questa specifica è un lavoro del W3C XML Protocol Working Group.

I partecipanti nel Working Group sono (nel momento della scrittura, per ordine alfabetico): David Fallside (IBM), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), John Ibbotson (IBM), Anish Karmarkar (Oracle), Suresh Kodichath (IONA Technologies), Yves Lafon (W3C), Michael Mahan (Nokia), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Jean-Jacques Moreau (Canon), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Herve Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Sono stati partecipanti previ: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (webMethods), Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems), Philippe Bedu (EDF (Electricite De France)), Olivier Boudeville (EDF (Electricite De France)), Carine Bournez (W3C), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell, Inc.), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Dave Cleary (webMethods), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (Excelon Corporation), Ron Daniel (Interwoven), Glen Daniels (Macromedia), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett Packard), James Falek (TIBCO Software, Inc.), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Mike Greenberg (IONA Technologies), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Frederick Hirsch (Zolera Systems), Erin Hoffmann (Tradia Inc.), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Limited), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Hewlett Packard, formerly of Compaq), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Limited), Murali Janakiraman (Rogue Wave), Mario Jeckle (DaimlerChrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (Systinet), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Bob Lojek (Intalio Inc.), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Nilo Mitra (Ericsson), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Highland Mary Mountain (Intel), Don Mullen (TIBCO Software, Inc.), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco Systems), Masahiko Narita (Fujitsu Limited), Mark Needleman (Data Research Associates), Art Nevarez (Novell, Inc.), Eric Newcomer (IONA Technologies), Henrik Nielsen (Microsoft Corporation), Conleth O'Connell (Vignette), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (DaimlerChrysler Research and Technology), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE Corporation), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera Systems), Krishna Sankar (Cisco Systems), George Scott (Tradia Inc.), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Miroslav Simek (Systinet), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Seumas Soltysik (IONA Technologies), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Anne Thomas Manes (Sun Microsystems), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (webMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (MartSoft Corp.).

Si ringrazia anche le persone che hanno contribuito alle discussioni presso xml-dist-app@w3.org .

Pacchetto Ottimizzato XML-binario

Raccomandazione W3C 25 Gennaio 2005

Riassunto

Stato di questo Documento

Contenuti

Appendici

1 Introduzione

1.1 Terminologia

1.2 Esempi

1.3 Convenzioni di Notazione

2 Strutture Infoset XOP

2.1 Item informazione dell'elemento `xop:Include`

2.2 Item informazione dell'elemento `href`

3 Modello di Processamento XOP

3.1 Creare Pacchetti XOP

3.2 Interpretare i Pacchetti XOP

4 Pacchetti XOP

4.1 Pacchetti XOP MIME Multipart/Related

5 Identificare Documenti XOP

5.1 Registrazione

6 Considerazioni di Sicurezza

6.1 Integrità del Pacchetto XOP

6.2 Riservatezza del Pacchetto XOP

A Relazioni con altre specifiche

A.1 Dipendenze

A.2 Payload

A.3 Extension

A.4 Requisiti

B Riferimenti

B.1 Riferimenti Normativi

B.2 Riferimenti Informativi

C Riconoscimenti (Non-Normative)

Pacchetto Ottimizzato XML-binario

Raccomandazione W3C 25 Gennaio 2005

Riassunto

Stato di questo Documento

Contenuti

Appendici

1 Introduzione

1.1 Terminologia

1.2 Esempi

1.3 Convenzioni di Notazione

2 Strutture Infoset XOP

2.1 Item informazione dell'elemento xop:Include

2.2 Item informazione dell'elemento href

3 Modello di Processamento XOP

3.1 Creare Pacchetti XOP

3.2 Interpretare i Pacchetti XOP

4 Pacchetti XOP

4.1 Pacchetti XOP MIME Multipart/Related

5 Identificare Documenti XOP

5.1 Registrazione

6 Considerazioni di Sicurezza

6.1 Integrità del Pacchetto XOP

6.2 Riservatezza del Pacchetto XOP

A Relazioni con altre specifiche

A.1 Dipendenze

A.2 Payload

A.3 Extension

A.4 Requisiti

B Riferimenti

B.1 Riferimenti Normativi

B.2 Riferimenti Informativi

C Riconoscimenti (Non-Normative)

2.1 Item informazione dell'elemento `xop:Include`

2.2 Item informazione dell'elemento `href`