2. 주요 기능 (Freatures at a Glance)

OOP

객체지향 프로그래밍은 Java와 같은 언어에서 존재하는 class와 interface를 통해 지원된다. (이 두 가지는 nominal type으로 알려져 있다.) 클래스 기반 프로그램밍은 프로그램을 만들고 재사용 가능한 라이브러리를 만드는데 있어 잘 알려진 방법이며 널리 가르쳐져 왔다. 게다가 웹 환경에서의 ECMAScript의 환경인 브라우저의 Document Object Model (DOM)은 class와 interface로 이우러져있다. ECMAScript를 확장 언어로 사용하는 다른 환경 역시 주로 클래스 기반 구조체에 의해 가장 잘 실현되는 객체 모델을 노출한다.

ES3에서 사용되던 Delegation 형식의 프로그래밍은 여전히 ES4에서 지원되며, 실제로도 클래스 기반 프로그래밍과 잘 융합된다.

마지막으로 ES4는 Multimethod 메커니즘을 이용해 Common Lisp, Dylan, Cecil 등에서 사용되는 프로그래밍 스타일을 지원한다. (이들 언어에서는 메서드의 정의는 메서드가 적용되는 타입의 정의와 결합되지 않는다.) Multimethod는 ES4가 연산자 오버로딩을 지원하기 쉽도록 한다.

Privacy

Modularity, name hiding, 라이브러리 구축은 packages와 namespace에 의해 지원되는데, 이것은 서로 분리되어 있는 모듈간에 견고한 API를 제공하고 type system과 함께 이름에 대한 접근 권한을 제어하는 기능을 제공한다.

타입(Types)

크고 일반적으로 검증가능하고 고성능의 프로그래밍은 풍부한 타입 시스템에 의해 지원된다. nomial type은 class와 interface에 의해 구현되며 ES3 프로그램에서 일반적인 ad hoc 데이터를 지원하기위한 구조적 타입에 의해 보충된다.

변수는 타입 제약을 가질 수 있으며 이때 구현은 타입 검사와 early binding을 수행한다. 타입이 있는 코드와 없는 코드가 예측가능한 방법으로 공존할수 있으며 완전히 타입이 있는 코드, 타입이 있는 라이브러리와 그렇지 않은 클라이언트 코드, 타입이 있는 API (package, class 또는 function 레벨에서)와 그렇지 않은 구현 코드 또는 임의로 타입을 사용하는 것 등 다양한 스타일을 지원한다.

타입이 없는 코드가 필요에 따라 점진적으로 타입을 지정할 수 있는 것 처럼, ad hoc 데이터 역시 필요에 따라 구조적 또는 명시적 타입을 지정할 수 있다. 타입이 없는 데이터는 로컬 데이터로 사용하고 노출되는 데이터 구조는 구조적 타입을 적용하고, 성능, 보안 또는 프로그램 구조상 필요가 있을 경우 명시적 타입으로 변환하여 지정할 수 있다.

검증(Verification)

프로그램 컴포넌트는 strict mode에서 컴파일 되도록 요청할 수 있으며, 이는 해당 컴포넌트가 실행되기 이전에 검증되도록 한다. 검증 단계는 정적 타입 검사(static type checking)을 수행하며 다른 정적인 검사들을 수행한다. 주로 참조된 모든 이름이 알려져 있는지, 참조된 객체의 속성의 타입이 알려져 있는지, 상수에 대한 쓰기는 없지는지, 다른 타입 간의 비교는 없는지 등과 같은 것들이다.

ES4의 검증은 static checker와 다른 언어 특히 Action Script의 Verifier에 있는 "lint" 기능을 모델로 삼았다. 검증 기능의 규범적 정의는 이러한 정의가 없을때 보다 ECMAScript 구현간 호환성을 촉진시킬 것이다. (ECMAScript 구현은 strict mode를 구현하는 대신 모든 프로그램을 표준 모드에서 동작시킬 수 있다.)

속도와 공간 최적화(Speed and space optimization)

타입 지정 기능은 호출될 메서드를 미리 바인딩함으로써 잠재적으로 ES3에 비해 메서드 호출 비용을 낮출 수 있다. 타입 지정은 또한 run-time 타입 검사를 컴파일러가 생략할 수 있도록 한다. int, uint, double과 같은 데이터 타입은 현대의 하드웨어에서 직접적으로 매핑되며 몇몇 타입에 대한 타입 특정적인 연산자를 통해 고성능 연산을 수행할 수 있도록 한다. 성능을 주요 목표로 설계된 Vector와 같은 데이터 타입은 매우 범용적인 Array와 같은 데이터 타입의 오버헤드를 범용성을 약간 희생하면서 없어지도록 한다.

더 적게 프로그램하기(Programming in the small)

타입이 전송되는 exception handling, block scoping, 문법적 속기(shorthand) 그리고 바인딩과 대입연산자의 destructuring은 코드를 더욱 간단하고 적은 노력으로 짤 수 있도록 해준다.

제어구문(Control)

표준 iteration과 itemization 프로토콜은 객체가 iteration 인터페이스를 노출 할 수 있도록 한다. for-in과 for-each-in 구문이 이 프로토콜을 활용한다.

Generator는 함수의 동작을 중단하고 caller에게 값을 리턴 한 뒤 나중에 caller가 연산을 재개할 수 있도록 한다.

Proper tail call은 재귀적 또는 상호 재귀적인 함수가 반복적인 형태로 표현될 수 있도록 한다. Tail call은 스택 공간의 부족에 대한 걱정 없이 절자척인 추상화를 사용할 수 있도록 한다.

데이타(Data)

ES4는 파라메터 있는 class, getter와 setter가 있는 클래스, 타입 있는 객체와 배열 구문, meta-level hook, reflection, destructuring, 프로그래머가 정의한 객체를 predefined 객체와 같이 사용할 수 있도록 하는 타입 시스템과 같은 기능을 제공한다.

Self-hosting

ES3는 이러한 사실을 언급하지 않았지만 ES3의 Object, Array와 같은 predefined data type은 class와 interface와 같은 nominal type으로 가장 잘 실현된다. 결과적으로 ES4에 있는 Object부터 Map까지의 모든 predefined 타입은 표준에서 언어 자체를 이용하여 정의되었다. 그래서 3rd edition에서 Array는 설명문과 Pseudocode로 정의된 메서드와 속성의 집합으로 표현되었으나, ES4에서는 클래스로 표현된며 ES4 code를 활용한 설명은 메서드의 의미를 필연적으로 설명문에 의한 것 보다 정확이 정의하고 data type의 완전한 의미를 포함한다.

Self-hosting은 언어 설계 과정에서 명확한 목표였다. Self-hosting은 두 가지 긍정적인 효과가 있다. 하나는 언어의 정의에 있어서 임의로 언어에서 정의되는 부분의 필요성을 줄여주고, 언어 자체에서 제공하는 기능과 동일한 강력한 기능을 사용자에게 제공한다. 이로인해 ES4를 위한 라이브러리와 스크립트의 강건한 체계를 만들 수 있도록 한다.

Portability

ES3와 마찬가지로 ES4 역시 다양한 기계에서 동작되기를 기대한다.

완전한 ES3 구현을 가진 현대적인 웹 브라우저들은 상대적으로 느린 하드웨어와 수 메가 바이트의 메모리에서도 성공적으로 동작한다. 프로그램은 소스 텍스트 형태로 전달되며 모든 컴파일은 기기에서 이루어지지만 짧은 반응시간과 상호동작성이 중요하다. 완전한 언어 구현은 매우 중요하다. - 웹은 3rd edition compact profile과 같은 서브셋 구현과 친하지 못하다. 결과적으로 ES4는 작은 디바이스에서도 구현 가능하지만 비용이 든다. 정교한 컴파일 타임 분석이 필요한 기능은 작은 기기 뿐만 아니라 일반적으로 제외할 수 있도록 되어있다. (예를 들면 구현은 strict mode를 반드시 구현해야 하는 것은 아니다.)

마찬가지로 몇몇 ES4 구현은 JVM이나 .NET과 같은 "hosted" 환경에서 존재할 것으로 보인다. 이러한 환경은 first-class continuation이나 stack mark와 같은 강력한 기능을 제공하지 않을 수도 있으며, 따라서 ES4는 이러한 기능을 최소화 하였다.

Formalism

무엇보다 좋은 표준은 모호하지 않고 완전하며 정확해야 한다. 3rd edition 표준은 테스트 불가능하고 지정되지 않았은 low level pseudocode를 이용하여 정의하였기 때문에 의미적인 부분의 정의가 힘들었고 이로 인해 나머지는 설명문에 의해 정의되었다. 실제적으로는 충분히 정확할 수 있을런지는 모르나, pseudocode는 읽고 쓰기가 어렵다 - 많은 오류가 발견되었으며 몇몇은 비공식 정오표에 나타나있다. 가끔 설명문은 설명해야 하는 내용을 모두 설명하지 못하지만 이러한 부적절한 설명은 해당 표준을 구현하기 전까지 이를 알아 내기 어렵다.

ES4가 ES3에 비해 상당히 커질 것은 분명했다. TG1 멤버들은 문서의 내용을 디버깅하기가 너무 어려울 것이기 때문에 ES3에서 사용하던 formalism 방법을 계속 사용하고 싶지 않았다. 더 나은 formalism 방법이 요청되었으며 E4X는 구조화된 pseudocode를 사용했으나 테스트 불가능하기는 마찬가지였다. 2003년 중간 보고서는 ES3나 E4X보다 formal한 Algol과 비슷한 pseudocode를 사용했으며 이를 위한 실행 엔진도 만들어 졌다. ES4를 위한 최근의 작업에서 TG1 멤버들은 Stratego를 포함한 term rewriting 언어를 사용하는 것을 검토하였다. 하지만 결국 TG1은 ES4와 이의 모든 predefined 클래스의 완전한 참조 구현(Reference Implementation)을 만들기로 결정하였으며 4th edition 부분을 RI에서 직접 참조하기로 했다. 게다가 RI는 TG1 멤버와 커뮤니티의 사용자들이 디자인 되고 있는 언어에 대한 실험을 수행할 수 있도록 하였다.

RI의 언어 처리기 부분은 Standard ML로 구현되었고, predefined 클래스는 ECMAScript를 이용해 구현되었다. RI는 TG1 멤버들이 ES3로 쓰여진 프로그램에 대한 호환성을 가지도록 만들어진 test suite를 활용해 테스트되었다.

1. 소개(Introduction)

역사(History)

ECMAScript 4th Edition (ES4)은 1995년부터 Netscape Communications社에 의해 개발된 Javascript를 근간으로하는 3rd edition (ES3)으로부터 진화한 multi-paradigm 언어이다.

ES4 작업은 1999년 3rd edition의 제정과 함께 시작되었다. 2003년 중간 보고서가 보고되었으며, 이후 작업은 중단되었다. 중간 보고서에 정의된 언어의 부분집합이 Adobe Systems의 ActionScript와 Microsoft의 JScript.NET에 의해 구현되었다.

현재 Ecma Technical Committee 39의 Task Group 1 (Ecma TC39-TG15, 이후 TG1)은 ES3, ES4의 중간 보고, 그리고 Adobe와 Microsoft의 구현에 관한 경험을 토대로 2005년 가을부터 작업을 시작했다. TG1은 2008년 가을 완성된 4th Edition 표준을 제정할 예정이다.

이 문서는 대다수의 Ecma TC39-TG1 멤버의 의견을 나타낸다. TG1의 일부는 이 문서에서 정의된 언어가 ES4가 되는 것에 동의하지 않는다. 하지만 ECMA와 ISO는 표준 제정에 만장일치를 요구하지 않으며, TG1에 다른 대안이 제시되지도 않았다. 따라서 이 문서에서 정의한 언어가 계속 ES4로 제안될 것이다.

ES3

ES3는 간단하고, 고도로 동적이며, 객체에 기반을 둔 언어로 Self와 Scheme으로 부터 주요한 특징들을 차용했다. 프로그래밍 스타일은 객체 기반과 함수형 프로그래밍을 섞어 놓았다. ES3의 주된 추상화 매커니즘은 lexically scoped higher-order functions과 delegation 매커니즘을 통해 접근가능한 메서드들을 가지는 prototype 객체를 가지는 mutable 객체이다. ES3는 C++와 Java와 유사한 문법을 가지고 있으며 loop와 exception 같은 제어 구조를 제공한다. 또한 array, string, number, date, regular expression과 같은 다양한 데이터 타입을 지원한다.

ES3는 독립적으로 여러번 구현되었으며 웹을 위한 언어 및 데스크탑과 어플리케이션을 위한 확장 언어로 널리 사용되고 있다.

ES4

ES3의 추상화 기능이 비록 유연하고 강력하지만, 가끔 큰 소프트웨어의 개발에는 적합하지 않은 경우가 있다. ECMAScript 프로그램들은 웹에서의 AJAX 프로그래밍과 어플리케이션에서 확장 또는 스크립트 언어로서의 사용이 증가함에 따라 점점더 크고 복잡해져 가고있다. 큰 프로그램의 개발은 static type checking, name hiding, early binding 그리고 객체 지향 프로그램의 직접 지원같은 기능으로부터 혜택을 받을 수 있는데 이러한 기능은 ES3에는 존재하지 않는다.

Goals

TG1의 목표는 ES4를 ES3와 호환가능하면서도 큰 소프트웨어 시스템 개발에 더욱 적합하게 만드는데 있다. 재사용 가능한 ES4 라이브러리의 제작을 촉진하고, 2003년 중간 보고 이후 독립적으로 구현된 기능들을 병합하고 다양한 단점을 보완하면서도 ECMAScript를 여전히 스크립트와 작은 프로그램을 짜기 쉬운 언어로 유지하는데 있다.

XMLHttpRequest 객체

W3C Working Draft 26 October 2007

이 버전:

http://www.w3.org/TR/2007/WD-XMLHttpRequest-20071026/

최신 버전:

http://www.w3.org/TR/XMLHttpRequest/

이전 버전들:

http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070618/

http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/

http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060927/

http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/

http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/

작성자:

Anne van Kesteren (Opera Software ASA) <annevk@opera.com>

번역자:

이해석 (Infraware) <97079258@infraware.co.kr>

Copyright © 2007 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

요약

The XMLHttpRequest Object 규격은 서버와 클라이언트간 데이터를 전달하기 위한 스크립트화된 클라이언트 기능을 제공하는 API를 정의한다.

이 문서의 상태

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the 26 October 2007 Working Draft of The XMLHttpRequest Object specification. Please send comments to public-webapi@w3.org (archived) with either [XHR] or [XMLHttpRequest] at the start of the subject line.

This document is produced by the Web API Working Group, part of the Rich Web Clients Activity in the W3C Interaction Domain. Changes made to this document can be found in the W3C public CVS server.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

목차

• 1. 소개
  • 1.1. 사용예
  • 1.2. 준수
    • 1.2.1. 의존성
    • 1.2.2. 용어
    • 1.2.3. 확장
• 2. XMLHttpRequest객체
  • 2.1. XMLHttpRequest의 이벤트
  • 2.2. XMLHttpRequest의 예외
• 본 규격에 정의되지 않은 것들
• 참조
• 감사의 말

1. 소개

이 절은 비규범적이다.

XMLHttpRequest object는 HTTP 클라이언트 인터페이스를 구현한다. 이 인터페이스는 스크립트 엔진을 통해 노출되며 폼 데이터를 보내거나 서버로부터 데이터를 받아오는 기능을 수행한다.

XMLHttpRequest라는 이름은 웹의 호환성을 위해 지어졌지만 이름의 각 부분은 잠재적으로 오해를 일으킬 수 있다. 첫째, XMLHttpRequest는 XML을 포함한 텍스트 기반의 어떠한 포맷도 지원한다. 둘째, XMLHttpRequest는 HTTP와 HTTPS 프로토콜 모두 사용할 수 있다. (몇몇 구현은 HTTP와 HTTPS 이외의 프로토콜을 지원하기도 하지만 그러한 기능은 본 규격에서는 다루지 않는다.). 마지막으로 XMLHttpRequest의 "request"는 HTTP에 정의된 용어에 비해 광의적으로 사용된다. 즉, HTTP method들을 위한 HTTP request와 response를 수행하기 위한 행위들을 포함한다.

1.1. 사용예

이 절은 비규범적이다.

몇몇 [ECMAScript] 예제들은 본 규격에 열거되었다. 추가로 아래 코드를 참고할 수 있다.

function test(data) { // taking care of data}function handler() { if(this.readyState == 4 && this.status == 200) { // so far so good if(this.responseXML != null && this.responseXML.getElementById('test').firstChild.data) // success! test(this.responseXML.getElementById('test').firstChild.data); else test(null); } else if (this.readyState == 4 && this.status != 200) { // fetched the wrong page or network error... test(null); }}var client = new XMLHttpRequest();client.onreadystatechange = handler;client.open("GET", "test.xml");client.send();

function log(message) { var client = new XMLHttpRequest(); client.open("POST", "/log"); client.setRequestHeader("Content-Type", "text/plain;charset=UTF-8"); client.send(message);}

function fetchStatus(address) { var client = new XMLHttpRequest(); client.onreadystatechange = function() { // in case of network errors this might not give reliable results if(this.readyState == 4) returnStatus(this.status); } client.open("HEAD", address); client.send();}

1.2. 준수(Conformance)

다이어그램, 예제, 노트 그리고 비규범적이라고 명시된 절을 제외한 본 문서의 모든 부분은 규범적이다.

이 문서에서 사용된 must, must not, should 와 may 이라는 용어는 RFC 2119 [RFC2119]에 따라 해석된다.

본 규격은 다음과 같은 종류의 산출물을 정의한다.:

준수하는 유저 에이전트

유저 에이전트는 본 규격에 준수하기 위해 반드시(must) 이 규격에 정의된 대로 동작해야 한다.

만약 유저에이전트가 XML 유저에이전트에 준수하지 않는다면 XML response entity body는 반드시(must) 항상 null이어야 한다.

유저 에이전트는 본 규격에 정의된 알고리즘으로 얻을 수 있는 결과물과 구별 불가능한 결과물을 얻는 알고리즘을 구현할 수 있다. (may)

본 규격에서 사용하는 "준수하는 유저 에이전트(들)"와 "유저 에이전트(들)"는 이 종류의 산출물은 가르킨다.

준수하는 XML 유저 에이전트

준수하는 유저 에이전트이면서 동시에 namespace well-formed를 보고하는 준수하는 XML처리기인 유저 에이전트를 말한다.[XML] [XMLNS]

1.2.1. 의존성

본 규격은 몇몇 기초 규격에 기반을 두고 있다.

DOM

준수하는 유저에이전트는 반드시(must) DOM Core와 DOM Events에 정의된 기능의 부분 집합을 지원해야한다. [DOM3Events] [DOM3Core]

이 규격이 의존하고 있는 반드시(must) Window Objects 1.0 규격에 정의된 기능의 부분 집합을 지원해야 한다. [Window ]

HTTP

준수하는 유저에이전트는 반드시(must) 특정버전의 HTTP를 지원해야 한다. 꼭(should) Method형식에 맞는 HTTP method를 제공해야 하며, 반드시(must) 최소한 아래의 method들을 지원해야 한다.:

• GET
• POST
• HEAD
• PUT
• DELETE
• OPTIONS

HTTP에 관한 다른 요구사항은 다음 문서에 정의되어 있다. [RFC2616]

1.2.2. 용어

s1 과 s2 문자열의 case-insensitive match는 두 문자열을 모두 대문자로 만들고 나서 (a-z를 A-Z로 매핑함으로써) 두 문자열이 동일함을 의미한다.

두 개의 URI는 RFC 3987에 정의된 sceheme-based normalization을 수행한 후에 scheme, ihost, port가 모두 동일 할 경우 same-origin 이라고 정의된다. 만약 URI가 두 URI 모두 ihost를 가지고 있지 않을 경우 반드시(must not) same-origin으로 간주되지 말아야 한다. [RFC3987]

1.2.3. 확장

본 규격에 정의된 API의 확장은 강력히 추천되지 않는다. 유저 에이전트들, 워킹 그룹, 그 밖에 관심있는 단체들은 반드시 이러한 확장을 public-webapi@w3.org 와 같은 공개적인 방법으로 논의 해야한다.

2. XMLHttpRequest 객체

XMLHttpRequest 객체는 스크립트에 의해 프로그램적으로 originating server에 접속할 수 있다.

XMLHttpRequest 인터페이스를 구현하는 객체는 반드시(must) EventTarget 인터페이스를 구현해야 한다. [DOM3Events]

Window 인터페이스를 구현하는 객체는 반드시(must) XMLHttpRequest() 생성자를 제공해야한다. [Window]

var client = new XMLHttpRequest();

XMLHttpRequest() 생성자가 호출될 경우 연관된 Window 객체에 대한 영속적인 포인터가 반드시(must) 새로 생성된 객체에 저장되어야 한다. 이것은 Window 포인터이다. 연관된 Window 객체는 XMLHttpRequest() 생성자가 호출된 것 중 하나이다. 이 포인터는 반드시(must) 해당 윈도우가 속해있는 브라우징 콘텍스트가 파괴된 경우에도 유지되어야 한다. (예를들면 부모 콘텍스트로 부터 제거하는 것과 같이).

브라우징 콘텍스트라는 용어는 Window Object 1.0 규격에 의해 정의된다. [Window]

var client = new win.XMLHttpRequest()

interface XMLHttpRequest {  // event handler           attribute EventListener onreadystatechange;  // state  const unsigned short UNSENT = 0;  const unsigned short OPENED = 1;  const unsigned short HEADERS_RECEIVED = 2;  const unsigned short LOADING = 3;  const unsigned short DONE = 4;  readonly attribute unsigned short readyState;  // request  void open(in DOMString method, in DOMString url);  void open(in DOMString method, in DOMString url, in boolean async);  void open(in DOMString method, in DOMString url, in boolean async, in DOMString user);  void open(in DOMString method, in DOMString url, in boolean async, in DOMString user, in DOMString password);  void setRequestHeader(in DOMString header, in DOMString value);  void send();  void send(in DOMString data);  void send(in Document data);  void abort();  // response  DOMString getAllResponseHeaders();  DOMString getResponseHeader(in DOMString header);  readonly attribute DOMString responseText;  readonly attribute Document responseXML;  readonly attribute unsigned short status;  readonly attribute DOMString statusText;};

XMLHttpRequest 객체는 다섯 가지 상태를 가질 수 있다: UNSENT, OPENED, HEADERS_RECEIVED, LOADING 그리고 DONE. 현재 상태는 readyState 속성에 의해 노출된다. 아래 정의된 방법이 언제 상태 전이가 일어나는지를 정의한다.

생성되었을 때, XMLHttpRequest객체는 반드시(must) UNSENT 상태여야 한다. 이 상태는 값이 0인 UNSENT 상수에 의해 표현된다.

OPENED 상태는 open() 메서드가 성공적으로 불렸을 때의 객체의 상태이다. 이 상태에서는 setRequestHeader()를 이용해 request 헤더를 설정할 수 있으며, send()를 통해 request를 할 수 있다. 이 상태는 값이 1인 OPENED 상수에 의해 표현된다.

OPENED 상태는 연관된 send() 플래그를 가지는데, "true" 또는 "false"의 값을 가진다. send() 플래그의 초기값은 "false"이다.

HEADERS_RECEIVED 상태는 모든 response 헤더가 받아진 객체의 상태이다. 이 상태는 값이 2인 HEADERS_RECEIVED 상수에 의해 표현된다.

LOADING 상태는 response entity body가 받아지고 있는 중의 객체의 상태이다. 이 상태는 값이 3인 LOADING 상수에 의해 표현된다.

DONE 상태는 데이터의 전송이 끝나거나 전송 중 무한 리다이렉션 같은 오류가 발생한 객체의 상태이다. 이 상태는 값이 4인 DONE 상수에 의해 표현된다.

DONE는 연관된 error 플래그를 가지며 그 값은 "true" 또는 "false"이다. error 플래그의 초기값은 "false"이다.

response entity body는 현재까지 수신된 entity body의 일부이거나 (LOADING 상태), 완전한 entity body 이다. (DONE 상태). 만약 entity body가 없다면 response entity body 는 "null"이다.

text response entity body는 response entity body를 나타내는 DOMString이거나 null이다. Text response entity body는 다음과 같은 알고리즘의 리턴값이다:

1. 만약 response entity body가 "null"이면, null을 리턴하고 종료한다.

2. charset을 "null"로 하자.

3. 만약 Content-Type 헤더가 없거나 MIME type이 text/xml , application/xml이거나 +xml로 끝나는 Content-Type 헤더를 가졌다면 (파라메터는 무시한다), character encoding을 판별하기 위해 XML 규격에 설명되어 있는 방법을 사용한다. charset을 판별된 character encoding 값으로 한다.

4. 만약 MIME type이 text/html인 Content-Type 헤더를 가졌다면, character encoding을 판별하기 위해 HTML 5 규격에 설명되어 있는 방법을 사용한다. charset을 판별된 character encoding 값으로 한다. [HTML5]

5. 만약 Content-Type헤더에 지정된 MIME type이 파라메터를 가지고 있고, charset이 "null" 이라면 charset이 그 파라메터의 값으로 한다.

   XML과 HTML 규격에 정의된 알고리즘은 이미 Content-Type 값을 참고한다.

6. 만약 charset이 "null"이면, 아래 테이블의 각 행을 첫 줄부터 시작해서 대조하여 처음으로 첫번째 열과 일치하는 행의 두번째 컬럼 값을 charset의 값으로 한다. 만약 일치 하는 행이 없다면 charset 는 "null"로 남는다.

   16진수 바이트열	설명
   00 00 FE FF	UTF-32BE BOM
   FF FE 00 00	UTF-32LE BOM
   FE FF	UTF-16BE BOM
   FF FE	UTF-16LE BOM
   EF BB BF	UTF-8 BOM

7. 만약 charset 이 "null"이면 charset를 UTF-8로 한다.

8. Response entity body를 charset를 이용해 디코딩 한 값을 리턴한다. 만약 실패한다면 null을 리턴한다.

XML response entity body는 response entity body를 나타내는 Document이거나 null이다. XML response entity body 는 다음과 같은 알고리즘의 리턴값이다:

1. 만약 response entity body가 "null"이면, null을 리턴하고 종료한다.

2. 만약 Content-Type 헤더가 존재하고 MIME type이 text/xml , application/xml이거나 +xml로 끝나는 Content-Type 헤더를 가지지 않았다면 (파라메터는 무시한다), null을 리턴하고 종료한다. (만약 Content-Type 가 전혀 없다면 종료하지 않는다.)

3. Response entity body를 XML 규격에 정의된 방법을 따라서 document tree로 파싱한다. parsed document의 값을 그 결과값으로 한다. 만약 지원되지 않는 character encoding이거나 namespace well-formedness 에러 등에 의해 실패한다면 null을 리턴하고 종료한다. [XML] [XMLNS ]

   Document tree에 있는 스크립트는 실행되지 않으며, 여기서 참조된 리소스들도 로딩되지 않는다. 또한 연관된 XSLT도 적용되지 않는다.

4. parsed document값을 가지는 Document 인터페이스를 구현한 객체를 리턴한다.

onreadystatechange of type EventListener

bubbling phase 동안readystatechange 이벤트가 전달될 경우 이 객체에 등록된 다른 적절한 이벤트 핸들러와 함께 반드시(must) 호출되어야 하는 EventListener를 값을 취하는 속성이다. 초기값은 반드시 (must) null이다.

readyState of type unsigned short, readonly

이 속성을 읽을 경우 반드시(must) 해당 객체의 현재 상태 값을 리턴해야 한다.

open(method, url, async, user, password), method

호출될 경우 유저 에이전트는 반드시(must) 다음 단계를 따라야 한다. (다른 방식으로 지시되지 않는 한):

1. 만약 method인자가 RFC 2616의 5.1.1절에 정의된 Method 형식에 맞지 않은 경우 SYNTAX_ERR 예외를 발생하고 종료한다. [RFC2616]

2. 만약 주어진 method 인자가 보안상의 이유로 지원되지 않을경우 유저 에이전트는 꼭(should) SECURITY_ERR 예외를 발생하고 종료해야 한다.

3. 저장된 method값을 method로 한다.

4. 만약 method가 GET, POST, HEAD, PUT, DELETE 또는 OPTIONS 와 case-insensitively match하다면 stored method에 이를 a-z를 A-Z로 매핑함으로써 대문자로 변환한 값을 저장한다.

5. url에 Fragment identifier가 있다면 이를 제외한 부분을 저장된 url값에 저장한다.

6. 만약 저장된 url이 상대적 경로라면, Window포인터에 연관된 Document 객체의 현재 baseURI 속성을 이용해 해결한다. 만약 이것이 실패한다면 SYNTAX_ERR 예외를 발생시키고 종료한다.

7. 만약 저장된 url이 지원되지 않는 scheme을 가졌을 경우, NOT_SUPPORTED_ERR 예외를 발생시키고 종료한다.

8. 만약 "user:password" 형식의 userinfo 값이 해당 scheme에서 지원되지 않고, 저장된 url값에 이 형식이 존재한다면, SYNTAX_ERR 예외를 발생시키고 종료한다. [RFC3986]

9. 만약 저장된 url 값이 "user:password" 형식을 가진다면 저장된 user 가 user 부분, 저장된 password 가 password 부분이 되도록한다.

10. 만약 저장된 url 이 "user" 형식만 가진다면, 저장된 user값이 user 부분이 되도록 한다.

11. 만약 저장된 url이 Window 포인터에 연관된 Document 객체와 same-origin이 아니라면, 유저 에이전트는 꼭(should) SECURITY_ERR예외를 발생시키고 종료해야 한다. 용어 origin은 HTML 5 규격에 의해 정의된다. [HTML5]

12. async 값을 async 인자의 값이 주어졌을 경우에는 그 값으로, 생략되었을 경우에는 true로 한다.

13. 만약 user 인자가 주어졌고, 그 형식이 해당 인증 scheme에 적합하지 않은 경우, SYNTAX_ERR 예외를 발생시키고 종료한다.

14. 만약 user 인자가 주어졌고 null이 아니라면 저장된 user 값을 해당 인증 scheme에 지정된 방법으로 인코딩한 값으로 한다. 만약 scheme에서 encoding이 지정되지 않은 경우에는 UTF-8로 인코딩 한 값으로 한다.

    이 단계는 url 인자에 의해 지정된 user 값보다 우선 순위를 가진다.

15. 만약 user 인자가 생략되지 않았고 null이라면 저장된 user 값을 지운다.

16. 만약 password 인자가 주어졌고, 그 형식이 해당 인증 scheme에 적합하지 않은 경우, SYNTAX_ERR 예외를 발생시키고 종료한다.

17. 만약 password 인자가 주어졌고 null이 아니라면 저장된 user 값을 해당 인증 scheme에 지정된 방법으로 인코딩한 값으로 한다. 만약 scheme에서 encoding이 지정되지 않은 경우에는 UTF-8로 인코딩 한 값으로 한다.

18. 만약 password 인자가 생략되지 않았고 null이라면 저장된 password 값을 지운다.

19. send() 알고리즘을 취소하고, response entity body를 "null"로 하고, request header의 목록들을 리셋한다.

20. 유저 에이전트는 꼭(should) 해당 객체가 수행하는 모든 네트워크 활동을 취소해야 한다.

21. 객체의 상태를 OPENED 상태로 세팅하고, send()플래그 값을 "false"로 새팅한다. 그리고 동기적으로 readystatechange 이벤트를 해당 객체에 보내고, 메서드 호출을 리턴한다.

본 규격의 향후 버전 또는 확장은 cross-site request에 대한 방법을 정의할 가능성이 높다.

setRequestHeader(header, value), method

각각의 request는 연관된 값을 지닌 request header 목록을 가진다. 이 메서드는 그 값을 조작하거나 새로운 request header를 지정하는데 사용할 수 있다.

호출 될 경우, 유저 에이전트는 반드시(must) 다음 단계를 따라야한다. (다른 방법으로 지시되지 않았을 경우):

1. 만약 객체의 상태가 OPENED 가 아닐 경우 INVALID_STATE_ERR 예외를 발생하고 종료한다.

2. 만약 send()플래그가 "true"라면, INVALID_STATE_ERR 예외를 발생하고 종료한다.

3. 만약 header 인자가 RFC 2616의 4.2절에 정의된 field-name 형식과 맞지 않거나 null 일 경우 SYNTAX_ERR 예외를 발생하고 종료한다. [RFC2616]

4. 만약 value 인자가 null 이라면 종료한다. (예외를 발생시키지 않는다.)

5. 만약 value 인자가 RFC 2616의 4.2절에 정의된 field-value 형식에 맞지 않는다면 SYNTAX_ERR 예외를 발생시키고 종료한다. [RFC2616]

6. 만약 header 인자가 아래의 값 중 하나와 case-insensitively match한다면 꼭(should) 보안상의 이유로 종료되어야 한다:

   • Accept-Charset
   • Accept-Encoding
   • Connection
   • Content-Length
   • Content-Transfer-Encoding
   • Date
   • Expect
   • Host
   • Keep-Alive
   • Referer
   • TE
   • Trailer
   • Transfer-Encoding
   • Upgrade
   • Via

7. 역시 보안상의 이유로 만약 header 인자의 첫 여섯글자가 Proxy-와 case-insensitively match 한다면 종료해야 한다.

8. 만약 header 인자가 request header 목록에 없다면 연관된 value를 목록에 추가하고 종료한다.

9. 만약 header 인자가 request header 목록에 있다면, 복수의 header를 사용하거나 값을 합치거나 그 두 개의 조합을 사용한다. (RFC 2616 4.2절) [RFC2616]

유저 에이전트가 캐싱, 인증, 프록시, 쿠키와 관련해서 header를 어떻게 다루는지 보려면 send() 메서드를 참조하다.

// 다음의 스크립트는:var client = new XMLHttpRequest();client.open('GET', 'demo.cgi');client.setRequestHeader('X-Test', 'one');client.setRequestHeader('X-Test', 'two');client.send();// ...아래와 같은 request header를 보내게 된다:...X-Test: one, two...

send(data), method

send() 메서드는 요청을 시작하며, 이의 선택적 인자는 entity body를 제공한다. 저작자들은 send()를 null이 아닌 data 인자와 함께 호출하기 전에 setRequestHeader()로 Content-Type header를 지정 했는지 확인 하도록 강력히 권장된다.

호출될 경우 유저 에이전트는 반드시(must) 다음의 단계를 따라야 한다. (다른 방식으로 지정되지 않았을 경우). 이 알고라즘은 open() 또는 abort()메서드가 호출됨으로써 취소될 수 있다. send() 알고리즘이 중단될 경우에 유저 에이전트는 반드시(must) 현재 진행 중인 단계를 끝내고 종료해야 한다.

아래 알고리즘은 async가 false일 경우, 스크립트를 통해 중단될 수 없다. 오직 async가 true 이고 해당 메서드가 리턴한 이후에만 중단될 수 있다.

1. 만약 객체의 상태가 OPENED 가 아니라면 INVALID_STATE_ERR 예외를 발생 시키고 종료한다.

2. 만약 send()플래그가 "true"라면 INVALID_STATE_ERR 예외를 발생시키고 종료한다.

3. 만약 async가 true라면 send()플래그를 "true"로 한다.

4. 만약 data 인자가 생략되지 않았고, null이 아니라면 이 값을 RFC 2616의 7.2절에 정의된 대로 entity body 값으로 사용하되 다음의 규칙을 따른다. [RFC2616]

   data가 DOMString이다.

   전송을 위해 data를 UTF-8로 인코딩한다.

   data가 Document이다.

   data를 namespace well-formed한 XML document로 직렬화(serialize)하고 data.xmlEncoding에서 주어진 값으로 인코딩한다. 만약 주어지지 않았을 경우 UTF-8로 인코딩한다. 만약 Document가 직렬화(serialize) 되지 못해서 실패한다면, data가 null인 것 처럼 동작한다.

   만약 Content-Type 헤더가 request header 목록에 존재하지 않는다면, request header 목록에 application/xml를 값으로 Content-Type 헤더를 추가한다.

   Document에 대한 이후의 변경은 전송되는 값에 영향을 미치지 않는다.

   data가 DOMString도 아니고, Document도 아니다.

   data의 호스트 언어에서 지정된 문자열화(stringification) 방법을 사용하고, data가 DOMString인 것처럼 동작한다. 만약 실패할 경우 data가 null인 것처럼 동작한다.

   만약 data 인자가 생략되었거나, null이라면 이 요청에서 entity body가 사용되지 않는다.

5. 이 단계 직후에 stored url에 stored method의 HTTP method, stored user의 user (만약 있다면), stored password의 password (만약 있다면), entity body와 request header 목록을 이용해 요청을 한다.

6. 동기적으로 readystatechange 이벤트를 객체에 보낸다.

   객체의 상태는 변경되지 않는다. 이 이벤트는 역사적인 이유로 보내지는 것이다.

7. 만약 async 가 true 라면 send() 메서드 호출을 리턴한다. (하지만 이 알고리즘을 종료하지는 않는다.)

8. 리소스가 다운로드 되는 동안 아래의 규칙이 적용된다.

   만약 response가 HTTP redirect라면

   만약 redirect가 보안상의 문제 점이 없고, (예를 들면 same-origin이라면) 무한 루프에 빠질 위험이 없다면 그 scheme은 투명하게(transparently) 지원되며, redirect를 따라간 후 이 단계 맨 처음으로 돌아한다.

   HTTP는 유저에이턴트가 redirect 하는 동안 request method와 entity body를 유지하도록 요구한다. 또한 이러한 자동 redirection이 사용자에게 알려지도록 요구한다.

   그렇지 않다면 다음의 단계를 따른다:

   1. response entity body를 "null"로 세팅하고 error flag를 "true"로 하고 request header 목록을 리셋한다.

   2. 동기적으로 객체의 상태를 DONE으로 전환한다.

   3. 만약 async 가 false 라면 NETWORK_ERR 예외를 발생시키고 전체 알고리즘을 종료한다.

   4. 동기적으로 readystatechange 이벤트를 객체에 보낸다.

   5. 전체 알고리즘을 종료한다.

   향후 버전의 XMLHttpRequest 객체는 여기에서도 error 이벤트를 보내게 될 가능성이 높다.

   만약 사용자가 다운로드를 취소한다면

   다음 단계를 수행한다:

   1. response entity body를 "null"로 세팅하고 error flag를 "true"로 하고 request header 목록을 리셋한다.

   2. 동기적으로 객체의 상태를 DONE으로 전환한다.

   3. 만약 async 가 false 라면 ABORT_ERR 예외를 발생시키고 전체 알고리즘을 종료한다.

   4. 동기적으로 readystatechange 이벤트를 객체에 보낸다.

   5. 전체 알고리즘을 종료한다.

   향후 버전의 XMLHttpRequest 객체는 여기에서도 abort 이벤트를 보내게 될 가능성이 높다.

   네트워크 에러가 발생한 경우라면

   DNS 에러 또는 다른 종류의 네트워크 에러의 경우 다음의 단계를 수행한다. 여기에는 HTTP status code 410과 같은 어떤 종류의 에러를 나타내는 HTTP response를 포함하지 않는다.

   1. response entity body를 "null"로 세팅하고 error flag를 "true"로 하고 request header 목록을 리셋한다.

   2. 동기적으로 객체의 상태를 DONE으로 전환한다.

   3. 만약 async 가 false 라면 NETWORK_ERR 예외를 발생시키고 전체 알고리즘을 종료한다.

   4. 동기적으로 readystatechange 이벤트를 객체에 보낸다.

   5. 전체 알고리즘을 종료한다.

   향후 버전의 XMLHttpRequest 객체는 여기에서도 error 이벤트를 보내게 될 가능성이 높다.

   만약 모든 HTTP 헤더들을 수신했다면

   message body(있다면)를 수신하기 전에 만약 모든 HTTP header들을 수신했다면 다음 단계를 따른다:

   1. 동기적으로 객체의 상태를 HEADERS_RECEIVED으로 전환한다.

   2. 동기적으로 readystatechange 이벤트를 객체에 보낸다.

   만약 response entity body의 첫 바이트 (또는 더 많은 바이트)를 수신했다면

   만약 response entity body가 없다면

   만약 response entity body의 첫 바이트 (또는 더 많은 바이트)를 수신했거나 response entity body가 없다면 다음의 단계를 따른다:

   1. 동기적으로 객체의 상태를 LOADING으로 전환한다.

   2. 동기적으로 readystatechange 이벤트를 객체에 보낸다.

   마지막으로, 리소스의 다운로드가 완료되면 다음 단계로 이동한다.

9. 해당 요청이 로딩을 성공적으로 끝내면, 동기적으로 상태를 DONE로 전환하고, 동기적으로 readystatechange 이벤트를 객체에 보낸다. 만약 async가 false라면 이 메서드를 리턴한다.

만약 유저 에이전트가 사용자가 프록시를 설정할 수 있도록 허용한다면 꼭(should) 적절히 요청을 수정해야 한다; 즉, origin server 대신 proxy host에 접속하고, Request-Line을 수정하며 Proxy-Authorization 헤더를 지정된 대로 보내야 한다.

만약 유저 에이전트가 HTTP 인증을 지원한다면 꼭(should) 이 객체로부터 발생한 request에 대해 보호된 영역으로 간주해야 한다. 즉, accessed URI를 포함하고 Authorization 헤더를 보내며 401 Unauthorized 요청을 적절히 처리해야한다. 만약 인증이 실패할 경우, 유저 에이전트는 꼭(should) 사용자에게 자격(credentials)에 대해 물어야 한다. [RFC2617]

만약 유저 에이전트가 HTTP State Management를 지원한다면 꼭(should) 적절히 쿠키를 저장하고, 제거하고, 보내야 한다. (Set-Cookie와 Set-Cookie2 response 헤더에 의해 받아지고, Cookie헤더에 의해 보내진다.) [RFC2965]

만약 유저 에이전트가 HTTP cache를 구현한다면 꼭(should) Cache-Control request 헤러들 준수해야 한다. (예, Cache-Control: no-cache는 cache를 사용하지 않는다.) 유저 에이전트는 사용자에 의해 명시적으로 요청된 경우가 아니라면 Cache-Control이나 Pragma헤더를 자동으로 보내서는 안된다(must not). (예, (강제로-)페이지를 Reloading할 경우). 유저 에이전트의 조건 요청에 따른 304 Not Modified response는 반드시(must) 적절한 콘텐트로 200 OK response처럼 보여져야 한다. 유저 에이전트는 304 Not Modified가 반드시(must) 전달되어야 할때 반드시(must) If-None-Match, If-Modified-Since와 같은 request header를 설정함으로써 자동 캐시 검증 방법보다 높은 우선 순위의 검증 방법을 제공할 수 있어야한다. [RFC2616]

만약 유저 에이전트가 서버 기반 content-nogotiation을 구현한다면 꼭(should) Accept-Language, Accept-Encoding와 Accept-Charset 헤더를 적절히 세팅해야한다; 자동으로 Accept 헤더를 세팅해서는 안된다(must not). 이러한 request에 대한 response에는 자동으로 디코딩된 content-encoding 들이 반드시must있어야 한다. [RFC2616]

abort(), method

호출될 경우 유저 에이전트는 반드시(must) 다음의 단계를 수행해야한다. (다른 방법으로 지시되지 않을 경우):

1. send()알고리즘을 취소하고, response entity body를 "null"로 세팅하고, error flag를 "true"로 한 뒤 등록된 모든 request header들을 제거한다.

2. 유저 에이전트는 꼭(should) 해당 객체가 수행하는 모든 네트워크 활동을 취소해야 한다.

3. 만약 상태가 UNSENT 또는 OPENED 이고 send()플래그 가 "false"이거나, 상태가 DONE 히면 다음 단계로 간다.

   그렇지 않을 경우 상태를 DONE으로 바꾸고, send()플래그를 "false"로 한 뒤, 동기적으로 객체에게 readystatechange 이벤트를 보낸다.

4. 객체 상태를 UNSENT로 바꾼다. (readystatechange 이벤트를 발생시키지는 않는다.)

   향후 버전의 XMLHttpRequest 객체는 여기에서도 abort 이벤트를 발생시킬 가능성이 높다.

getAllResponseHeaders(), method

호출될 경우 유저 에이전트는 반드시(must) 다음의 단계를 수행해야한다:

1. 만약 상태가 UNSENT 또는OPENED라면 INVALID_STATE_ERR 예외를 발생시키고 종료한다.

2. 만약 error flag 가 "true" 라면, null을 리턴하고 종료한다.

3. 모든 HTTP 헤더를 리턴한다. 이는 단일 문자열로 이루어지며 각각의 헤더 라인은 상태 라인을 제외하고는 U+000D CR U+000A LF 짝으로 분리된다.

// 아래의 스크립트는:var client = new XMLHttpRequest();client.open("GET", "test.txt", true);client.send();client.onreadystatechange = function() { if(this.readyState == 3) { print(this.getAllResponseHeaders()); }}// ...다음과 유사한 텍스트를 출력해야 한다:Date: Sun, 24 Oct 2004 04:58:38 GMTServer: Apache/1.3.31 (Unix)Keep-Alive: timeout=15, max=99Connection: Keep-AliveTransfer-Encoding: chunkedContent-Type: text/plain; charset=utf-8

getResponseHeader(header), method

호출될 경우 유저 에이전트는 반드시(must) 다음의 단계를 수행해야한다:

1. 만약 상태가 UNSENT 또는 OPENED라면 INVALID_STATE_ERR 예외를 발생시키고 종료한다.

2. 만약 header 인자가 field-name형식에 맞지 않는 다면 빈 문자열을 리턴하고 종료한다.

3. 만약 error 플래그 가 "true"라면 null을 리턴하고 종료한다.

4. 만약 header 인자가 마지막으로 보낸 request의 헤더들 중 여러 개와 case-insensitively match 한다면, 이 헤더들의 값을 U+002C COMMA와 그 뒤에 U+0020 SPACE로 구별되는 한 개의 문자열로 합쳐서 리턴하고 종료한다.

5. 만약 header 인자가 마지막으로 보낸 request의 헤더들 중 한 개와 case-insensitively match 한다면, 이 헤더의 값 리턴하고 종료한다.

6. null을 리턴한다.

// 아래의 스크립트는:var client = new XMLHttpRequest();client.open("GET", "test.txt", true);client.send();client.onreadystatechange = function() { if(this.readyState == 3) { print(client.getResponseHeader("Content-Type")); }}// ...다음과 같은 문자열을 출력해야 한다:Content-Type: text/plain; charset=utf-8

responseText of type DOMString, readonly

얻을때, 유저 에이전트는 반드시(must) 다음과 같은 단계를 수행해야 한다:

1. 만약 상태가 LOADING 또는 DONE이 아니라면 INVALID_STATE_ERR 예외를 발생시키고 종료한다.

2. text response entity body를 리턴한다.

responseXML of type Document, readonly

얻을때, 유저 에이전트는 반드시(must) 다음과 같은 단계를 수행해야 한다:

1. 만약 상태가 DONE이 아니라면 INVALID_STATE_ERR 예외를 발생시키고 종료한다.

2. XML response entity body를 리턴한다.

status of type unsigned short, readonly

얻을때, 존재한다면 이는 반드시(must) 서버에서 보내진 HTTP status code를 리턴해야 한다. (보통 성공적인 요청에 대해서는 200 이다). 존재하지 않는 다면 유저 에이전트는 반드시(must) INVALID_STATE_ERR 예외를 발생시켜야 한다.

statusText of type DOMString, readonly

얻을때, 존재한다면 이는 반드시(must) 서버에서 보내진 HTTP status text를 리턴해야 한다. (status code 바로 뒤에 있다). 존재하지 않는다면 유저 에이전트는 반드시(must) INVALID_STATE_ERR 예외를 발생시켜야 한다.

2.1. XMLHttpRequest 객체의 이벤트

이 절은 XMLHttpRequest 인터페이스를 구현한 객체가 보내는 다양한 이벤트에 대해 설명한다. 이 버전의 규격에서는 한 개의 이벤트만 정의되어 있다.

readystatechange

유저 에이전트가 readystatechange 이벤트를 발생시킬 경우에는 (위에서 지시된바와 같이) bubble 하지 말아야 하며(must not), cancelable 하지 않아야 하고(must not), 반드시(must) Event 인터페이스를 구현해야한다. 이의 namespaceURI 속성은 반드시(must) null이어야 한다. [DOM3Events]

2.2. XMLHttpRequest 객체의 예외

이 규격에서 정의된 몇몇 알고리즘은 예외를 발생시킬 수 있다. 이 예외들은 모두 DOM Level 3 Core에서 정의된 ExceptionCode의 일부이며 DOMException 객체를 사용한다. 여기에 더해 본 규격에서는 ExceptionCode 에 아래와 같은 새로운 상수들을 정의한다. [DOM3Core]

const unsigned short SECURITY_ERR = 18;const unsigned short NETWORK_ERR = 101;const unsigned short ABORT_ERR = 102;

SECURITY_ERR 예외는 유저 에이전트의 보안 정책에 위배되거나 보안상의 위험이 있는 방식으로 동작을 수행하거나 데이터에 접근할 경우 발생한다.

SECURITY_ERR 예외는 궁극적으로 DOM Level 3 Core 규격의 향후 버전에 동일한 정의와 상수값으로 포함되어야 한다. 그 때까지 구현자에 대한 가이드로서 여기에 정의된다. (이것은 다른 예외들과 다른 상수값을 가지는 이유이기도 하다.)

NETWORK_ERR 예외는 동기적인 요청에서 네트워크 에러가 생겼을때 발생한다.

ABORT_ERR 예외는 동기적인 요청에서 사용자가 요청을 취소했을 때 발생한다.

본 규격에 정의되지 않은 것들

이 절은 비규범적이다.

본 규격은 향후 버전의 규격에서 고려되고 있는 다음과 같은 기능들을 포함하지 않는다:

• load 이벤트와 onload 속성;
• error 이벤트와 onerror 속성;
• progress 이벤트와 onprogress 속성;
• abort 이벤트와 onabort 속성;
• 타이머가 제안되었으며, ontimeout 속성이 고려 중;
• redirect를 막는 속성;
• text/html 문서에 대한 responseXML;
• Cross-site XMLHttpRequest;
• 바이트 스트립을 다루기위한 responseBody;
• MIME 타입을 수정하기 위한 overrideMimeType;
• getRequestHeader()와 removeRequestHeader().

참조

[DOM3Core]

Document Object Model (DOM) Level 3 Core Specification, A. Le Hors, P. Le Hégaret, L. Wood, G. Nicol, J. Robie, M. Champion, S. Byrne, editors. W3C, April 2004.

[DOM3Events]

Document Object Model (DOM) Level 3 Events Specification (work in progress), Björn Höhrmann, editor. W3C, April 2006.

[ECMAScript]

ECMAScript Language Specification, Third Edition. ECMA, December 1999.

[HTML5]

HTML 5 (work in progress), Ian Hickson, editor. WHATWG, 2007.

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997.

[RFC2616]

Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, editors. IETF, June 1999.

[RFC2617]

HTTP Authentication: Basic and Digest Access Authentication, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart, editors. IETF, June 1999.

[RFC2965]

HTTP State Management Mechanism, D. Kristol, L. Montulli, editors. IETF, October 2000.

[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, editors. IETF, January 2005.

[RFC3987]

Internationalized Resource Identifiers (IRIs), M. Duerst, M. Suignard, editors. IETF, January 2005.

[Window]

Window Object 1.0 (work in progress), I. Davis, M. Stachowiak, editors. W3C, April 2006.

[XML]

Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, F. Yergeau, editors. W3C, September 2006.

[XMLNS]

Namespaces in XML (Second Edition), T. Bray, D. Hollander, A. Layman, R. Tobin, editors. W3C, August 2006.

감사의 말

이 절은 비규범적이다.

The editor would like to thank to the following people who have contributed to this specification (ordered by first name):

• Ahmed Kamel
• Alex Hopmann
• Alex Vincent
• Alexey Proskuryakov
• Asbjørn Ulsberg
• Boris Zbarsky
• Björn Höhrmann
• Cameron McCormack
• Christophe Jolif
• Charles McCathieNevile
• Dan Winship
• David Håsäther
• Dean Jackson
• Denis Sureau
• Doug Schepers
• Douglas Livingstone
• Elliotte Harold
• Eric Lawrence
• Gideon Cohn
• Gorm Haug Eriksen
• Hallvord R. M. Steen
• Håkon Wium Lie
• Ian Davis
• Ian Hickson
• Ivan Herman
• Jeff Walden
• Jens Lindström
• Jim Deegan
• Jim Ley
• Joe Farro
• Jonas Sicking
• Julian Reschke
• Karl Dubost
• Maciej Stachowiak
• Magnus Kristiansen
• Marc Hadley
• Marcos Caceres
• Mark Baker
• Mark Nottingham
• Mohamed Zergaoui
• Pawel Glowacki
• Robin Berjon
• Ruud Steltenpool
• Simon Pieters
• Stewart Brodie
• Sunava Dutta
• Zhenbin Xu

Special thanks to the Microsoft employees who first implemented the XMLHttpRequest interface, which was first widely deployed by the Windows Internet Explorer browser.

Special thanks also to the WHATWG for drafting an initial version of this specification in their Web Applications 1.0 document (now renamed to HTML 5). [HTML5]

Thanks also to all those who have helped to improve this specification by sending suggestions and corrections. (Please, keep bugging us with your issues!)

IPTV와웹2.0 서비스

2008년 1월 Pre-IPTV를 포함한 국내 IPTV 서비스 가입자가 100만을 넘었다. 이로서 IPTV는 기술 개발을 위한 프로토타입이나 얼리어답터의 전유물이 아닌 대중적인 서비스로서 첫발을 내디뎠다고 볼 수 있다. 그러나 현재까지의 IPTV 서비스는 VOD 서비스를 위주로 기존의 유료방송을 IP 망으로 옮겨놓은 수준에서 크게 벗어나지 못하고 있다. 현재 시점은 IPTV가 기존 유료 방송과 차별화된 가치를 제공하고 장기적으로 영속되는 서비스로 자리 매김 할 수 있는지 여부에 대해 도마 위에 올랐다고 볼 수 있다. 본 고에서는 통신망을 활용한 양방향 서비스 미디어로서 IPTV의 차별화 포인트를 인터넷에서 개방, 참여, 공유 등을 기치로 한 웹 2.0을 매개로 풀어보고자 한다.

1. 웹2.0의8가지디자인패턴

웹 2.0은 O’Reilly Media 대표인 Tim O’Reilly가 닷컴 버블 시절 만들어진 다양한 서비스를 제공하던 벤처들의 붕괴 이후 실제로 수익을 내면서 살아남은 서비스 들의 공통된 특징을 ‘웹 2.0’이라고 부르자고 한데서 유래한다.[1] 닷컴 버블 시절 인터넷은 무한한 가능성을 제공할 신시장으로 생각되었고, 많은 창업자들은 기존 오프라인에서 운영되는 공급자 중심의 폐쇄적인 사업 모델을 인터넷으로 올리기만 하면 큰 성공을 거둘 것으로 생각했다. 시장도 닷컴업체에게 그러한 기대를 걸었고, 수익 한 푼 내지 못하는 벤처 기업들은 벤처 캐피탈과 주식시장을 통해 어마어마한 자금을 끌어 모았다. 하지만 이러한 기업들은 결국 수익을 내지 못하고 엄청난 적자에 시달리다가 파산하면서 결국 버블의 붕괴라는 최후를 맡는다.

비록 많은 기업이 실패했지만 인터넷은 실제로 사용자들에게 많은 가치를 제공했고, 이러한 가치를 제공한 기업들은 버블의 붕괴에도 불구하고 살아남았다. 그리고 현재 이들 기업은 실제 적은 수익을 기반으로 승승장구 중이다. Tim O’Reilly는 이러한 기업들의 사례를 분석하여 성공적인 웹 2.0 서비스를 만들기 위한 디자인 패턴[2]으로 다음과 같은 8가지를 꼽았다. 

<표1> 성공적인웹2.0 서비스를위한8가지디자인패턴

특징	설명
롱 테일 법칙 (The Long Tail)	20%의 상품이 80%의 매출을 차지한다는 오프라인 상점의 2:8 법칙은 온라인에서는 통하지 않는다. 무한한 상품 또는 서비스 리스트를 가지고 잘 팔리는 상품뿐만 아니라 찾기 힘든 상품 및 서비스까지 제공해야 한다.
데이터는 차세대 인텔 인사이드 (Data is the Next Intel Inside)	남이 흉내 내서 만들기 힘든 데이터를 소유하고, 이를 내외부의 다양한 서비스에서 활용하게 하는 플랫폼을 구축해야 한다.
사용자에 의한 부가가치 창조 (Users Add Value)	가치는 공급자가 만들고, 그 가치를 사용자가 소비한다는 개념이 아닌 사용자가 곧 가치 창조의 원천이다.
네트워크 효과를 재촉하는 초기설정 (Network Effects by Default)	적극적인 콘텐트 생성과 같은 사용자의 기여뿐만 아니라, 조회, 추천 등 기본적인 유저의 데이터도 활용해야 한다.
일부 권리 보유 (Some Rights Reserved)	다수의 사용자와 네트워크 효과에 의해 가치가 발생하는 인터넷의 특성상 까다로운 저작권은 오히려 방해가 된다.
영구 베타판 (The Perpetual Beta)	제품 개발 후 판매라는 구조는 통하지 않는다. 지속적으로 사용자의 피드백을 받아 조금씩 서비스를 개선해야 한다.
컨트롤이 아닌 협력 (Cooperate, Don't Control)	서비스의 이용을 자사 서비스에 제한하여 컨트롤하는 폐쇄적인 모델 보다는 Open API를 통해 서비스의 확산을 통한 다른 서비스와의 연계를 노려라.
단일 디바이스를 넘는 소프트웨어 (Software Above the Level of a Single Device)	PC이외의 디바이스에서도 서비스를 사용할 수 있도록 하라.

자료원: O'Reilly Network

2. Web 2.0관점에서본IPTV사업방향

닷컴 기업의 붕괴와 웹 2.0이라는 개념의 등장은 IPTV에게 시사하는 점이 많다. 마치 초기 닷컴 기업들이 오프라인 서비스 모델을 온라인에 그대로 옮기면 성공할 것이라고 생각했던 것처럼, IPTV 사업자들도 유료 방송 모델을 그대로 인터넷 망으로 올리면 성공할 수 있을 것이라고 보는 듯하다. 현재 IPTV 서비스를 서비스 중인 KT, 하나로텔레콤, LG데이콤 모두 현재는 IPTV 법안 이슈로 Pre-IPTV 서비스를 제공하고 있다. Pre-IPTV는 VOD 위주의 서비스를 기반으로 월정액 또는 PPV (Pay Per View, 건당 과금 방식) 모델의 과금 방식을 채택하고 있다. 하지만 IPTV 사업자들은 사업 초기 사용자 확보를 위하여 3개월 또는 그 이상 무료 체험 기간을 제공하고 있어, PPV 콘텐트의 이용과 ARPU의 증가는 부진한 편이다. 이는 초기의 닷컴 기업들이 수익을 내기 위한 계획 없이 사용자를 확보하는 데만 주력하던 인터넷의 무료 서비스나 인터넷 공간에서 과금에 대한 저항으로 인해 사용자 확보에 실패한 유료 서비스를 닮았다. 지금은 서비스 개시 1~2년 만에 100만 가입자를 모으는 등 승승장구하고 있지만 수익 모델 확보에 실패한다면 빛 좋은 개살구로 전락하고 말 것이다. 이러한 상황에서 IPTV가 지속적으로 사용자를 유인하기 위해서는 웹 2.0 기업들이 채택했던 방법들을 주목할 필요가 있다.

2.1. 롱테일법칙

현재 Pre-IPTV 서비스의 주된 서비스는 VOD이다. 특히 월 정액 금액으로 제공되던 지상파 방송 다시보기 서비스는 사용자가 가장 많은 서비스이다. 인터넷 방송사 홈페이지에서 다시보기 서비스를 이용하거나 불법적인 경로로 다운로드 받아서 사용할 수 있음에도 누구나 손쉽게 TV에서 지나간 지상파 방송을 골라서 볼 수 있다는 점은 많은 사용자에게 어필했다. 하지만 IPTV 뿐만 아니라 위성/케이블 등 유선 방송, DMB, 인터넷 등 다양한 매체가 생겨나면서 지상파 콘텐트에 대한 경쟁을 부추겼고 결국 지상파 콘텐트의 가격은 천정부지로 높아지고 있다. 지상파 콘텐트뿐만 아니라 유명 영화나 해외 드라마 역시 이러한 가격 상승을 나타내고 있고, 급기야 최근에는 지상파 콘텐트의 경우 방송 후 7일 이내 유료화라는 결정마저 내려지고 만다. 이 같은 사실은 VOD 위주의 현재 서비스뿐만 아니라 향후 채널 기반의 서비스가 도입되더라도 마찬가지 일 것이다. 결국 현재와 같은 구조에서 고가의 “인기 콘텐트”위주 서비스가 초기 가입자수를 늘리는 데에는 효과가 있을지 몰라도 이를 가지고 수익을 올리기는 쉽지 않음을 보여준다.

롱 테일 법칙은 사용자가 많은 킬러 콘텐트 보다는 콘텐트의 다양성을 활용해 사용자를 확보해야 함을 보여준다. 생활 수준의 향상으로 사용자들의 콘텐트에 대한 욕구는 다양해졌다. 한국의 드라마나 할리우드의 외화를 제외하고도 미국의 드라마나 일본의 애니메이션 같은 경우는 이미 대중적인 인기를 얻은 수준이며 다양한 마니아 계층은 각자 그들이 선호하는 콘텐트가 존재한다. 기존 방송 매체는 단방향성 특성으로 인해 이러한 욕구를 충족시켜줄 수 없었지만 인터넷 망을 기반으로 무한한 양의 콘텐트를 서비스 할 수 있는 IPTV는 상황이 다르다고 볼 수 있다.

다른 곳에서 구하기 어려운 콘텐트일수록 사용자들의 가격에 대한 저항감은 떨어질 것이고, 반대로 세분화된 콘텐트를 시청하는 사용자에 대한 광고는 노출 대비 효과가 높아질 것이다.

2.2. 데이터는차세대인텔인사이드

CPU는 컴퓨터 내부에 들어가 있어서 사용자에게 보여지지 않기 때문에 일부 컴퓨터 전문가를 제외하고는 인지하기 쉽지 않은 제품이다. 인텔에게 있어서 이러한 사실은 표준화 되어가는 x86 아키텍처에서 AMD 등 다른 경쟁사와 차별화 하기가 힘들다는 것을 의미한다. 인텔은 이에 대응하여 HP, 델, 컴팩, 삼성뿐만 아니라 각국의 수많은 중소 기업들까지 다양한 제조사에서 생산되는 PC를 인텔 인사이드라는 브랜드로 묶어놓았다. 인텔은 인텔 인사이드 전략을 통해 자신의 핵심역량인 CPU, 반도체에 집중해서 경쟁력 있는 제품을 만드는 한편 소비자의 인지도를 확보할 수 있었다. 그래서 소비자들은 CPU에 대해서 잘 모르지만 인텔 인사이드 마크가 들어가 있으면 믿을 수 있게 되었고, 제조사들은 이러한 인지도가 있는 인텔의 CPU를 적극 채택하였다. 만약 인텔이 이러한 전략 대신 직접 PC까지 생산하는 전략을 가져갔다면 어떻게 되었을까? 인텔은 CPU를 파는 대신 PC 제조사들과 경쟁을 해야 했을 것이고, 핵심역량에 투자해야 할 역량을 이러한 데 쏟아 부으면서 결국 자멸했을 것이다.

웹이나 IPTV에서도 이러한 전략은 똑같이 유효하다. IPTV 사업자나 대형 포탈들이 굳이 IPTV의 수직적인 구축을 모두 맡는 것은 비용대비 효과나 서비스의 다양성 면에서 효과적이지 못하다. 구글이 지도 서비스를 Open API를 통해 제공하자 부동산 중개 업자들은 이를 활용한 중개 서비스를 내놓고, SNS 사업자들은 이를 활용한 친구 찾기 서비스를 내놓았듯이 지도, 음원 등 남들이 구축하기 힘든 데이터베이스를 구축하고 이를 활용토록 한다면 직접 모든 것을 구축하고 서비스할 때에 비해 핵심역량인 데이터베이스 구축에 집중하면서도 다양한 서비스를 내놓을 수 있을 것이다. IPTV에서는 프로그램 메타데이터, 사용자의 프로그램 평가 및 선호 데이터, 시청 행태 등 방송 시청 관련 데이터가 물론 가장 중요한 데이터 중 하나가 될 것이고, 여기에 더해 지도, 음원 등 부가 서비스를 위한 다양하고 방대한 데이터를 먼저 구축하고 퍼트릴 수 있는 기업이 중요한 위치로 등극할 것이다.

2.3. 사용자에의한부가가치창조

2006년 우리를 열광하게 했던 월드 베이스볼 클래식을 기억할 것이다. 연승행진으로 4강까지 올랐던 우리는 안타깝게도 일본에게 패배하여 국민들의 마음을 아프게 하였다. 이때 방송계에서는 사용자들의 방송 시청 형태를 송두리째 바꿀만한 엄청난 변화가 있었는데, 그것은 인터넷 매체의 시청자 수가 텔레비전 방송의 시청자 수를 누른 것이다.[3] 물론 방송 시간이 주로 낮 시간으로 직장인들이 집에서 텔레비전으로 보기 힘든 시간이라는 점이 작용했겠지만, ‘방송 = 텔레비전’이라는 공식을 바꿀만한 획기적인 사건이었다. 이러한 인터넷 시청률 증가에는 위치적 제약 없이 인터넷만 있으면 어디서나 볼 수 있다는 점과 함께 TV와는 달리 인터넷이 댓글 등을 통해서 다른 사용자와 교감할 수 있다는 점이 가장 큰 원인으로 꼽혔다. 인터넷 시청자의 상당수가 TV와 인터넷을 동시에 시청했다는 점에서 이러한 시청률 증가가 위치적 제약 때문만이 아님을 보여준다. 즉, 사용자는 단순히 방송 화면이 아니라 방송 화면과 이를 주변 사람과 공유하는 것을 포함한 전체적인 방송 경험을 중요시 여겼고, 화질이라던지 많은 사용자 수에 의한 끊김 현상 등에 있어서 TV에 비해 훨씬 열악한 방송 화면에도 불구하고 다른 사용자와의 소통이 가능한 인터넷 매체를 선택한 것이다.

양방향 매체인 IPTV는 방송화면의 공급자가 방송에 대한 모든 가치를 제공한다는 패러다임을 벗어나서 공급자와 시청자가 함께 전체적인 방송 경험을 만들어 간다는 사실을 깨달을 필요가 있다. 위에서 예를 든 실시간으로 댓글 등을 주고 받으며 대화할 수 있는 기능뿐만 아니라 프로그램에 관련된 커뮤니티나 관련 정보들을 주고 받을 수 있는 대화의 창을 제공하고 이를 통해 사용자 간 커뮤니케이션을 통해 방송의 부가가치가 높아지는 점을 활용해야 할 것이다.

2.4. 네트워크효과를재촉하는초기설정

최근의 블로그나 UCC 열풍은 마치 모든 사용자들이 콘텐트 저작자로 등극하고 있는 착각을 불러일으킬 만하다. 물론 인터넷의 발전이 콘텐트 저작자로서의 진입장벽을 낮춘 점은 인정이 되지만, 여전히 적극적인 콘텐트 생산자는 소비자에 비해서 상당히 적은 것이 사실이다. 하지만 성공적인 웹 2.0 서비스들은 이러한 사용자들도 부가가치를 창조하도록 하는 시스템을 갖추고 있다. 적은 부담으로 콘텐트에 기여하는 한줄댓글 같은 기능이라던지, 아니면 조회, 추천, 태깅 등 콘텐트를 소비하기 위해 무의식적으로 행하는 일들을 기록하여 제공하는 추천시스템 등이 바로 그것이다.

이른바 린백(Lean-back) 미디어, 즉 소파에 기대어 최소한의 개입으로 수동적으로 시청하는 TV 시청자의 특성상 이러한 시스템의 개발은 필수적이다. TV 서비스에서 가장 중요한 것으로 뽑히는 전자 프로그램 가이드(EPG) 서비스를 예를 들어 보자. 지상파 방송이나 케이블 또는 위성 같은 유료 방송에서 제공되는 채널 수는 적게는 4~5개, 많아야 100여 개 정도에 불과하였다. 하지만 사용자 방송 등의 개념까지 포함하면 사실상 무한개의 채널을 제공하는 IPTV에서 Grid 형식 또는 Mosaic 형식으로 화면에서 원하는 서비스를 선택하는 방식은 더 이상 유효하지 못하다. 여러 사람들이 보았거나 추천하는 콘텐트를 보여 준다던지, 기존 시청자가 보았던 프로그램과 유사한 프로그램을 보여준다던 지 하는 다양한 시스템이 도입되어야 한다. 실제로 사업자들이 수만 편의 VOD를 제공하면서도 사용자가 재미있다고 느낄만한 콘텐트를 찾지 못하는 현상은 이러한 시스템의 도입이 필수적이란 사실을 말해준다.

2.5. 일부권리보유

방송과 저작권은 무척 밀접하게 연결된 문제이다. 인터넷의 발전으로 음반 산업과 영화 산업이 위기에 처한 현실은 저작권이 얼마나 중요한 문제인지를 보여준다. 하지만 엄격한 저작권이 곧 수입 증대로 이어질 것이라는 기대는 금물이다. 음반 시장을 보아도 일반적인 유통 경로를 통했다면 음반 가격이 비싸서 아무도 사지 않고 묻혀버렸을 신인가수가 불법 복제 테이프의 유포로 유명해지거나 자신의 곡들을 인터넷에 올려놓아 유명해져 돈을 번 가수들도 있다. UCC 열풍이 불고 있는 웹 공간에서는 이러한 현상이 더욱 두드러져서 무료로 마음껏 볼 수 있는 블로그 공간에 글을 올리면서도 한달에 수 백만원 이상의 수입을 올리는 스타 블로거들이 늘고 있다. 물론 여기서 저작권 폐지론 등을 얘기하고자 하는 것은 아니다. 다만 저작권자들이 정말 자신이 지켜야 할 권리가 무엇이고, 어떻게 사용자들을 만족시켜서 그러한 권리에 응당한 대가를 받아 낼 것이냐가 중요하다. 사용자들은 이제 더 이상 단순한 음악/영화 감상에 돈을 쓰려하지 않는다. 반면에 음악/영화 감상을 포함한 즐거운 시청 경험에는 돈을 아끼지 않는다. 인터넷 상에서 500원~1000원 하는 영화 감상에는 돈을 쓰지 않으면서, 멀티플랙스 영화관에서 친구와 영화를 보는데는 1~2만원도 아끼지 않는 것을 보면 알 수 있다. IPTV에서도 물론 제공되는 콘텐트에 대한 저작권이 보호되고 유통되어야 하겠지만 사용자의 시청 경험에 반하는 엄격한 제약은 피해야 한다. 일부 저작권자들이 요구하는 것처럼 영화나 음반을 개작한 2차 UCC 산출물의 저작에 대한 제약 등이 그렇다. 마치 YouTube 같은 서비스가 콘텐트를 판매하는 것이 아니라 콘텐트를 보는 사용자들의 관심을 광고주들에게 파는 것처럼 새로운 비즈니스 모델을 구축하고 이 모델에 반하지 않는 이상 저작권의 제약을 최소화 할 필요가 있다.

2.6. 영구베타판

기존 TV 라는 매체에서 플랫폼 자체의 업그레이드는 사실상 거의 없었다. 흑백 TV에서 컬러 TV로 넘어온 것과 아날로그 TV에서 디지털 TV로 변한 것이 전부이다. 물론 브라운관, 프로젝션, LCD, PDP 등 하드웨어의 발달을 꼽을 수도 있겠지만 사용자에게 보이는 서비스가 본질적으로 변한 것은 아니었다. 따라서 사용자들은 10년 전에 산 컬러 TV를 가지고 여전히 문제 없이 TV를 볼 수 있는 대신 10년 전이나 지금이나 TV에서 나오는 내용은 달라졌을는지 몰라도 TV라는 서비스 자체는 완전히 정체되어 있다.

하지만 IPTV는 이와는 다르다. 가깝게 국내 사업자들의 예를 들어봐도 KT의 메가TV와 하나로텔레콤의 하나TV의 경우, 하루가 멀게 메뉴 구성을 업데이트 하다가 최근엔 대대적인 서비스 업그레이드를 단행하였다. 단순히 TV를 가능하면 깨끗하게 시청할 수 있게 해주는 기능만 수행하면 되었던 기존의 TV와는 달리 IPTV는 양방향을 비롯한 다양한 서비스를 제공하는 매체로서 시시각각 변하는 사용자들의 욕구를 만족시켜야 한다. 이를 위해서는 사용자를 만족 시킬 수 있는 최소한의 서비스로 시작하고 피드백을 통해 발전해 나가는 것이 최선의 전략일 것이다. 한번에 모든 플랫폼을 구축하고 그 위에서 콘텐트만 추가해나가면 될 것이라는 생각으로는 변화하는 사용자의 욕구를 충족시킬 수 없다. IPTV가 무한한 주기를 가지는 소프트웨어 개발 과정, 즉 ‘영구 베타판’상태임을 잊어서는 안된다.

2.7. 컨트롤이아닌협력

웹에서 가장 성공적인 서비스로 꼽히는 구글이나 네이버와 같은 검색 서비스는 인터넷 공간에 존재하는 다양한 정보 중에서 원하는 정보를 찾아주는 서비스이다. 물론 여기서 정보란 구글이나 네이버가 직접 구축한 것이 아닌 다양한 콘텐트 저작자들이 인터넷에 공개한 것이다. 만약 이들이 없다면 구글이나 네이버가 존재하지 못함은 자명하다. 만약 구글이나 네이버가 이러한 정보들을 자체 구축하려 한다면 천문학적인 비용이 들 뿐만 아니라 지금과 같은 다양성을 확보한다는 것은 불가능할 것이다. 검색 서비스가 성공적인 서비스로 자리매김 할 수 있었던 데에는 콘텐트 저작자들이 자율적으로 콘텐트를 생성하고 만들 수 있었다는 점과 구글이나 네이버가 다양한 광고 프로그램 등을 통해 이들이 수익을 얻을 수 있도록 한 점이 작용했다. 반면 방송시장은 전통적으로 방송사가 자체 제작 또는 프로덕션으로부터 프로그램을 구매하여 방송하는 중앙 집중적인 모델을 가지고 있었다. 전파수 등의 자원이 유한한 상황에서 가능한 많은 사용자에게 유용한 정보 위주로 방송을 해야 할 필요가 있었기 때문이다.

IPTV는 무한한 채널 자원을 가지고 있다는 점에서 인터넷 환경과 닮았다. 2.1절에서 언급한 롱 테일 전략을 펼치기 위해서는 다양한 이해관계자들과의 협력이 필수적이다. 기존 방송 매체와 동일한 접근 방식으로는 사용자들이 원하는 수준의 다양성 확보가 불가능할 것이다. 비록 서비스 초기에는 일정 수준의 콘텐트를 빠르게 확보하기 위해 IPTV 사업자가 콘텐트를 직접 제작 또는 외주하는 방식을 취한다고 할지라도 향후 많은 콘텐트 사업자들이 다양한 서비스를 할 수 있는 기반을 닦는 것이 매우 중요하다.

2.8. 단일디바이스를넘는소프트웨어

컨버전스와 디버전스라는 단어는 최근 디지털 기기 시장의 화두다. 전화는 기본이고 라디오/음악 감상, 인터넷, 게임 심지어 TV 시청까지 가능한 휴대폰의 등장은 상상할 수 있는 거의 모든 디지털 서비스가 가능한 것처럼 보인다. 그렇다면 이러한 휴대폰의 등장으로 사람들이 쓰는 디지털 기기의 숫자가 줄었을까? 그렇지 않다. 여전히 사람들은 집에서는 방송을 보기 위해서는 TV를, 인터넷을 하기 위해서는 PC를 사용한다. 매니아들은 게임을 위한 게임기와 음악 감상을 위한 오디오를 추가적으로 갖추기도 한다. 휴대용 기기에서도 마찬가지여서 휴대폰에서 음악 감상이 가능하지만 여전히 아이팟과 같은 MP3나 PMP를 가지고 다니는 사람 역시 많다. 다양한 서비스가 가능한 기기가 있음에도 더욱 많은 기기를 사용하게 되는 이유는 음질이나 화질, 이동성, 즐길 수 있는 게임의 종류 등이 각각의 기기마다 차이가 나고 상황에 따라 가장 적합한 기기가 다르기 때문이다. 소득 수준이 높아질수록 비용이 조금 더 들더라도 더 나은 서비스를 받고 싶어하기 때문에 사람들은 각각의 상황에 맞는 기기들을 더 많이 구매하게 된다. 하나의 기기에서 점점 더 다양한 서비스를 즐길 수 있게 되는 컨버전스 현상과 하나의 서비스를 점점 더 다양한 기기에서 즐길 수 있게 되는 디버전스 현상이 동시에 일어나고 있는 것이다. IPTV 역시 하나의 서비스로 보자면 같은 서비스 또는 연계된 서비스를 다양한 기기에서 즐기고자 하는 욕구는 충분하다. 예를 들어 거실에서 STB를 통해 보던 영화를 외출하면서 휴대용 기기를 통해 계속 보고 싶어하는 욕구 같은 것들 말이다. IPTV 서비스 역시 단순히 인터넷으로 연결된 STB나 TV에서 방송을 보는 서비스로 자리매김 하기보다는 보다 다양한 기기 및 상황에서 사용할 수 있는 총괄적인 서비스로 자리 메김 해야 한다.

3. 결론

IPTV 법제화, SKT의 하나로텔레콤 인수 등 IPTV를 둘러싼 최근 방송/통신 시장이 무척이나 시끄럽다. 이러한 변화의 반대편에 선 사람들은 이러한 변화가 다양한 사업자간의 공정한 경쟁을 촉진하기 보다는 규제산업으로 보호받으며 성장해온 거대 통신 기업 위주로 시장에게 방송시장을 내줌으로써 결국 소비자의 편익을 감소시킬 것이라는 논리를 펴고 있다. 만약 IPTV 서비스가 기존 유료 방송을 그대로 인터넷 망에 올려놓는 수준에 머무르고 시장이 거대 기업의 자금력에 의한 과당 경쟁으로 치닫는다면 이들의 걱정은 현실화 될 것이다. 기존 매체의 복사본이라는 평을 들으면서 재벌 기업들에게 방송을 허용하는 수단이라는 소리를 듣지 않으려면 IPTV가 기존 매체가 주지 못하던 가치를 제공하는 것이 중요하다. 이러한 가치를 제공하기 위해 개방, 참여, 공유라는 기치를 내건 웹 2.0이 IPTV에 시사하는 바는 크다고 볼 수 있다. 마치 인터넷의 등장으로 사람들의 삶을 획기적으로 바꾸고 삶의 질을 증가시킨 것과 같은 변화가 IPTV에서도 일어나기를 기대한다. 여기에 더해 말로만 인터넷 강국이지 알고 보면 PC방만 많았지 결국 전부 외국의 기술과 장비를 거금을 주고 구축한 것뿐이었다는 위기의식을 느끼고 있는 인터넷의 전철을 밟지 않아야 한다. 그렇기 위해서는 정부와 사업자들이 단순히 가입자 수치뿐만 아니라 앞선 기술 및 서비스를 개발하고, 국제 시장을 선점하려는 노력이 필요하다.

1. 해외생활
   세상에는 200~300만원으로 둘이서 충분히 생활할 수 있는 곳이 많다. 필리핀은 50만원이면 가정부가 딸린 집을 렌트 할 수 있고, 중국, 태국 등 자세히 알아보진 않았지만 좀 더 찾아보면 지금과 같이 도심이 아닌 자연과 더불어 살만한 곳이 있을 것 같다. 다만 도심은 아니어도 인터넷은 어느정도 잘 되는 곳으로 알아볼 것! (한국 처럼 빠른 것을 바라진 않는다. 웹 서핑하고 이메일쓰고 블로그 관리할 정도?)


2. 비용
   1년에 3,000~4,000만원하는 비행기값+생활비가 결국 제일 문제. 그동안의 저축 그리고 한 1년정도 더 일을한다고 생각하면 1년치 비용 정도는 어찌 마련해볼 수 있지 싶다. 지금 사는 집은 월세를 주면 생활비 일부 해결 가능.


3. 이동
   한 도시/위치에서 3~6개월, 한 국가에서 1년~1년반 생활을 하면 다른 곳으로 옮기는 것이 원칙! 항상 새로운 느낌을 갖고 싶다.


4. 언어
   가능하면 새로운 언어를 배울 수 있는 곳이면 금상첨화! 따라서 스페인어를 쓰는 남미 쪽이나 기타 비영어권 국가도 괜찮은 선택! 최근 좀 알아보고 있는데, 물가도 싸고 스페인어를 배울 수 있는 아르헨티나도 괜찮은 선택!


5. 운동
   한국에서는 늘 바쁘다는 핑계로 운동을 못하는데, 새로운 삶에서 운동과 언어 배우기는 생활의 중심! 스킨스쿠버, 춤, 격투기 등 한국서 배우기 힘든 종목 한 가지씩 배우기!


6. 프로그래밍
   특히 그동안 관심은 많았지만 실제로 건드려보지 못하던 인공지능, 컴파일러, 인지과학 등의 주제와 연결된 프로젝트라면 OK! 오픈 소스 프로젝트에 참여하는 것이 아주 좋을 듯! 물론 해당 프로젝트에서 날 받아준다는 보장은 없지만, 뭐 노력하다 보면 어찌 되겠지. 하여튼 돈과 상관 없이 정말 해보고 싶었던 주제의 프로그래밍을 하는 것이 목표! (웹 쪽도 좋긴 하지만 회사에서 했던 것이니 이쪽으로 하기는 조금...)


7. 돈벌기
   이게 관건인데, 오픈 소스 개발을 하면서 관련된 책쓰기, 번역 등으로 원격에서 돈을 벌 수 있다면 최고. 아니면 원격으로 할 수 있는 프로그래밍 플젝 등도 해볼 것. 일단 눈높이는 한달에 100~150만원만 벌기. 생활비가 충족되는 수준이면 그 이상 너무 오래 일하고 싶은 생각은 없다.


8. 일과
   하루 4시간 운동 & 여행 & 놀기, 4시간 언어 배우기, 4시간 프로그래밍 및 일하기, 주말에는 완전 놀기! 생각만 해도 행복하다.


9. 최악의 결과
   돈벌기는 완전 실패, 따라서 1년후 3,000~4,000만원은 완전 소진후 한국 귀환. 다시 적당한 회사를 찾아서 취직(1년 놀았다고 취직이 안되려나 ㅋㅋ). 그래도 1년간의 해외 생활 경험은 남음. 최소한 열심히 했다면 1개국어를 추가적으로 사용할 수 있게되고, 지금보다는 훨씬 건강한 몸과 마음을 가짐. (사고나 천재 지변 같은 경우는 제외한 최악의 결과, 이건 한국에 있어도 날 수 있는 거니까)


10. 최상의 결과
    원격 근무로 생활비 충족 가능. 저축의 일부는 소진하지만 지속적으로 새로운 나라를 경험하며 살 수 있음. 오픈소스 플젝과 관련 책등이 인정받아 조그만 필드라도 나름 전문가로 인정받음. 3년 뒤면 1~2개국어를 추가로 하고, 다양한 외국인과 친구가 됨. 그 이후 외국에서 바로 취업 또는 한국으로 돌아와서 취업.

물론 아직은 공개된 웹이라기 보다는 TV 환경에 맞춘 Closed Portal 형식이지만, 다양한 웹 표준을 지원하는 만큼 향후에는 다양한 인터넷 서비스가 가능해질 것으로 생각합니다. TV 네이버 같은 경우에도 인터넷 상의 서비스와 연계한 검색/블로그/UCC 등의 기능을 제공하고 있습니다. 앞으로 IPTV 외에도 케이블이나 지상파와 같은 TV 환경, 그리고 더 나아가 좀 더 다양한 디바이스에 웹을 적용하고 언제 어디서나 원하는 정보/서비스를 찾을 수 있는 환경을 만들어가겠습니다.

• HDTV에서 인터넷을?