본 발명의 원리는 전자 메시지 관련 데이터를 효율적으로 저장 및 액세스하는 데에 있다. 일반적으로, 전자 메시지는 전자 메시지 스키마 계층구조에 따라 생성된다. 전자 메시지는 서로 다른 타입의 전자 메시지 사이에서(예컨대, 전자 우편 메시지와 인스턴트 메시지 사이에서) 일부 데이터 필드들이 공통적으로 정의되도록 생성될 수 있고(예컨대, 주제 필드, 참가자 필드, 중요도 필드 등), 다른 데이터 필드, 예컨대 특별한 메시지 프로토콜 및/또는 특별한 메시지 애플리케이션에 특정된 데이터 필드는 다른 타입의 전자 메시지들 사이에서 별도로 정의된다(예컨대, 뉴스 그룹 포스팅의 PosterID 및 전자 우편 메시지의 삭제된 필드). 따라서, 전자 메시지는 다른 전자 메시지들과 공통인 일부 필드 및 다른 전자 메시지와는 다른 일부 필드를 가질 수 있다. 공통적으로 정의된 일부 필드 및 다르게 정의된 다른 필드를 가지면, 전자 메시지의 효율적인 기억 및 액세스가 촉진되고, 또한 기존의 메시지 프로토콜 및 메시지 애플리케이션과의 메시지 호환이 용이해진다.
본 발명의 범위 내의 실시예들은 컴퓨터 실행가능 명령 또는 저장된 데이터 구조를 운반하거나 갖고 있는 컴퓨터 판독가능 매체를 포함한다. 이와 같은 컴퓨터 판독가능 매체는 범용 또는 특수용 컴퓨터 시스템에 의해 액세스될 수 있는 이용 가능 매체일 수 있다. 예로서 그러나 제한적이지 않게, 이와 같은 컴퓨터 판독가능 매체는 RAM, ROM, EPROM, CD-ROM 또는 다른 광학 디스크 기억 장치, 자기 디스크 기억 또는 다른 자기 기억 장치와 같은 물리적 기억 매체, 또는 컴퓨터 실행가능 명령, 컴퓨터 판독가능 명령, 또는 데이터 구조의 형태의 원하는 프로그램 코드 수단을 운반 또는 저장하는 데에 사용될 수 있고 범용 또는 특수용 컴퓨터 시스템에 의해 액세스될 수 있는 다른 매체를 포함할 수 있다.
본원의 설명 및 후술되는 청구의 범위에서, "네트워크"는 컴퓨터 시스템들 및/또는 모듈들 간의 전자 데이터의 전송을 가능하게 하는 하나 이상의 데이터 링크로서 정의된다. 정보가 네트워크 또는 다른 통신 접속(유선, 무선, 또는 유선과 무선의 조합)을 통해 컴퓨터 시스템에 전달 또는 제공될 때, 접속은 컴퓨터 판독가능 매체로서 적절히 여겨진다. 따라서, 이러한 접속은 적절히 컴퓨터 판독가능 매체라고 불린다. 상기 조합은 또한 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다. 컴퓨터 실행가능 명령은 예컨대, 범용 컴퓨터 시스템 또는 특수용 컴퓨터 시스템이 일정한 기능 또는 한 그룹의 기능을 수행하도록 하는 명령 및 데이터를 포함한다. 컴퓨터 실행가능 명령은 예컨대 어셈블리어 또는 심지어 소스 코드와 같은 2진의 중간 포맷 명령일 수 있다.
본원의 설명 및 후속의 청구의 범위에서, "컴퓨터 시스템"은 전자 데이터에 대해 연산을 수행하기 위해 함께 동작하는 하나 이상의 소프트웨어 모듈, 하나 이상의 하드웨어 모듈, 또는 그 조합으로서 정의된다. 예컨대, 컴퓨터 시스템의 정의는 개인용 컴퓨터의 운영 체제와 같은 소프트웨어 모듈뿐만 아니라 개인용 컴퓨터의 하드웨어 구성 요소를 포함한다. 모듈들의 물리적인 레이아웃은 중요하지 않다. 컴퓨터 시스템은 네트워크를 통해 연결된 하나 이상의 컴퓨터들을 포함할 수 있다. 마찬가지로, 컴퓨터 시스템은 전자 데이터에 대해 연산을 수행하기 위해 내부 모듈들(예: 메모리 및 프로세서)이 함께 작업하는 단일 물리 장치(예: 휴대폰 또는 PDA(Personal Digital Assistant))를 포함할 수 있다.
본원의 설명 및 후술되는 청구의 범위에서, "스키마"는 복수의 컴퓨터 시스템들 간의 공유 어휘의 정의된 표현으로서, 복수의 컴퓨터 시스템들이 상기 표현되는 공유 어휘에 따라 문서를 처리할 수 있도록 한다. 예컨대, XML(eXtensible Markup Language) 스키마는 XML 스키마 언어의 스키마 구성(예컨대, 이름/값의 쌍)을 이용하는 XML 문서의 클래스를 정의 및 기술할 수 있다. 이들 스키마 구성은 XML 문서에서 사용되는 의미, 용도, 및 데이터 타입들 간의 관계, 구성 요소들 및 그 내용, 속성 및 그 값, 엔터티 및 그 내용, 및 표기를 제약하고 첨부하는 데에 사용될 수 있다. 따라서, XML 스키마를 액세스할 수 있는 컴퓨터 시스템은 XML 스키마에 따라 XML 문서를 처리할 수 있다. 또한, XML 스키마를 액세스할 수 있는 컴퓨터 시스템은 XML 스키마를 또한 액세스할 수 있는 다른 컴퓨터 시스템 및/또는 메시지 프로세서에 의한 사용을 위해 XML 문서를 구성(compose) 또는 수정(modify) 할 수 있다.
스키마는 예컨대, ".dtd" 확장자로 끝나는 DTD 파일과 같은 DTD(Document Type Definitions)를 포함하도록 정의된다. 스키마는 또한 예컨대 ".xsd" 확장자로 끝나는 XML 스키마 파일과 같은 W3C(World Wide Web Consortium) XML 스키마를 포함하도록 정의된다. 그러나, 실제로 특별한 DTD 또는 XML 스키마의 파일 확장자는 중요하지 않다. 스키마는 데이터 구조를 정의하는 데에 사용된 논리, 2진수, 8진수, 10진수, 16진수, 정수, 부동소숫점, 문자, 문자열, 사용자 정의된 데이터 타입, 및 이들 데이터 타입의 조합을 포함하는 데이터 타입을 가상적으로 정의하는 데에 사용될 수 있다. 사용자 정의된 데이터 타입의 일부 예는 날짜 및 시간 데이터를 나타내는 DateTime 데이터 타입, 및 예컨대 전화 번호, 전자 우편 주소, 인스턴트 메시지 주소 등과 같은 전자 주소 데이터를 나타내는 Eaddress 데이터 타입이다. 데이터 타입(또는 엔터티)은 링크 스키마 계층구조 내의 다른 데이터 타입(또는 엔터티)을 참조 또는 링크하기 위해 정의될 수 있다.
당업자는 본 발명이 개인용 컴퓨터, 랩탑 컴퓨터, 핸드헬드 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 또는 프로그래머블 소비자 전자 제품, 네트워크 PC, 미니 컴퓨터, 메인프레임 컴퓨터, 이동 전화, PDA, 페이저 등을 포함해서 많은 타입의 컴퓨터 시스템 구성을 갖는 네트워크 컴퓨팅 환경에서 실시될 수 있음을 알 수 있다. 본 발명은 또한 네트워크를 통해 (유선 데이터 링크, 무선 데이터 링크, 또는 유선 및 무선 데이터 링크의 조합에 의해) 링크되는 로컬 및 원격 컴퓨터 시스템들이 작업을 수행하는 분산 시스템 환경에서 실시될 수도 있다. 분산 시 스템 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 기억 장치에 위치될 수 있다.
도 1은 본 발명의 원리에 따라 전자 메시지 관련 데이터를 효율적으로 저장 및 처리하는 것을 용이하게 하는 네트워크 구조(100) 및 일반 스키마 계층구조(150)의 예를 나타낸다. 네트워크 구조(100)는 컴퓨터 시스템(102), 컴퓨터 시스템(109), 데이터베이스(114) 및 네트워크(121)를 포함한다. 컴퓨터 시스템(102) 및 컴퓨터 시스템(109)은 대응 링크(106)에 의해 연결된다. 컴퓨터 시스템(102) 및 컴퓨터 시스템(109)은 링크(106)를 통해 전자 메시지(예컨대, 전자 우편 메시지, 인스턴트 메시지, 팩스 메시지, 뉴스 그룹포스팅, 음성 메시지 등)를 교환할 수 있다. 예컨대, 컴퓨터 시스템(109)은 전자 메시지를 저장하는 메시징 서버이다. 때때로, 컴퓨터 시스템(102)은 전자 메시지를 다운로드하기 위해 컴퓨터 시스템(109)에 연결될 수 있다.
컴퓨터 시스템(109)은 링크(123)에 의해 데이터베이스(114)에 연결된다. 데이터베이스(114)는 복수의 다른 타입의 데이터베이스 아이템을 저장하는 데이터베이스일 수 있다. 예컨대, 콘택 사일로(182)는 콘택(예컨대, 개인, 조직, 또는 회사)을 나타내는 콘택 아이템을 저장할 수 있고, 폴더 사일로(183)는 다른 타입의 아이템(예컨대, 전자 메시지)를 저장하는 폴더를 나타내는 폴더 아이템을 저장할 수 있고, 메시지 사일로(184)는 전자 메시지를 나타내는 메시지 아이템을 저장할 수 있고, 문서 사일로(186)는 각종 문서 등을 나타내는 문서 아이템을 저장할 수 있다. 데이터베이스(114)에 저장된 데이터베이스 아이템은 스키마 계층구조(150) 의 스키마에 따라 정의된 데이터 필드를 포함할 수 있다. 콘택 사일로(182)의 뒤에 그리고 문서 사일로(186)의 앞에 있는 일련의 3개의 마침표(생략부호)는 (잠재적으로 다른 상이한 타입 데이터베이스 아이템을 저장하는) 다른 사일로가 데이터베이스(114) 내에 포함될 수 있음을 나타낸다.
컴퓨터 시스템(109)은 링크(118)에 의해 네트워크(121)에 연결된다. 네트워크(121)는 근거리 통신망("LAN"), 광대역 통신망("WAN"), 또는 심지어 인터넷일 수 있다. 컴퓨터 시스템(109)은 링크(118)를 통해 네트워크(121)에 연결된 다른 컴퓨터 시스템에 대해 데이터를 송수신할 수 있다. 네트워크(121)에 연결된 컴퓨터 시스템(102), 컴퓨터 시스템(109), 및 가능한 다른 컴퓨터 시스템은 스키마 계층구조(150)에 포함된 스키마를 액세스할 수 있다.
스키마 계층구조(150)는 일반적으로 전자 메시지를 정의하기 위한 데이터 포맷을 나타낸다. 전자 메시지를 나타내는 메시지 아이템(및 데이터베이스(114) 내의 다른 타입의 아이템)은 기본 아이템 스키마(151)에 따라 정의될 수 있다. 일반적으로, 기본 아이템 스키마는 다른 데이터베이스 아이템과 하나의 데이터베이스 아이템을 차별화하는 데에 사용되는 데이터 필드(예컨대, 글로벌 고유 ID 및 디스플레이명)의 데이터 포맷을 정의할 수 있다. 따라서, 메시지 사일로(184)(및 아이템 저장된 콘택 사일로(182), 폴더 사일로(183), 및 문서 사일로(186))에 저장된 메시지 아이템은 기본 아이템 스키마(151)에 따라 정의된 하나 이상의 데이터 필드를 포함할 수 있다.
메시지 스키마(152)는 복수의 서로 다른 타입의 전자 메시지에 공통적인 하 나 이상의 데이터 필드(예컨대, 메시지 주제, 메시지 크기 등)의 데이터 포맷을 정의한다. 메시지 스키마(152)는 예컨대, 텍스트 포맷 또는 하이퍼텍스트 마크업 언어("H1ML") 포맷과 같은 공통 포맷을 정의할 수 있다. 따라서, 메시지 사일로(184)에 저장된 메시지 아이템은 메시지 스키마(152)에 따라 정의된 하나 이상의 데이터 필드를 포함할 수 있다. 메시지 사일로(184)에 저장된 메시지 아이템은 또한 하나 이상의 메시지 확장 스키마에 따라 정의된 데이터 필드를 포함할 수 있다. 메시지 스키마(152)는 스키마 계층구조(150)의 다른 스키마에 따라 정의된 데이터 필드를 참조 또는 링크하는 데이터 필드를 저장할 수 있다.
예컨대, 메시지 스키마(152)는 콘택 사일로(182) 내의 콘택 관련 정보(콘택 스키마(153)에 따라 정의된 데이터 필드를 가짐)를 참조 또는 링크하는 하나 이상의 데이터 필드를 정의할 수 있다. 따라서, 메시지 스키마(152)에 따라 정의된 메시지 아이템은 콘택 사일로(182) 내의 콘택 관련 정보를 참조 또는 링크할 수 있다. 콘택 관련 정보를 참조 또는 링크하면, 콘택 관련 정보에 대응하는 엔터티가 메시지 아이템에 연관되는 것을 나타낼 수 있다. 유사하게, 메시지 스키마(152)는 (폴더 스키마(154)에 따라 정의된 데이터 필드를 갖는) 폴더 사일로(183) 내의 폴더 관련 정보를 참조 또는 링크하는 하나 이상의 데이터 필드를 정의할 수 있다. 따라서, 메시지 스키마(152)에 따라 정의된 메시지 아이템은 폴더 사일로(183) 내의 폴더 관련 정보를 참조 또는 링크할 수 있다. 폴더 관련 정보를 참조 또는 링크하면, 메시지 아이템이 폴더 관련 데이터에 대응하는 폴더 내에 저장되는 것을 나타낼 수 있다.
마찬가지로, 메시지 스키마(152)는 링크 문서 관련 정보를 참조 또는 링크하는 하나 이상의 데이터 필드를 정의할 수 있다. 따라서, 스키마(152)에 따라 정의된 메시지 아이템은 문서 사일로(186) 내의 문서 관련 데이터를 참조 또는 링크하는 (첨부 파일 스키마(157)에 따라 정의된 데이터 필드를 갖는) 하나 이상의 첨부 파일을 포함할 수 있다. 문서 관련 데이터를 참조 또는 링크하면, 문서 관련 데이터에 대응하는 문서가 메시지 아이템의 첨부 파일이었음을 나타낼 수 있다. 예컨대, 메시지 아이템은 워드 프로세싱 문서, 카렌다 약속, 사진 등과 같은 첨부 파일을 포함할 수 있다. 첨부 파일이 스키마화될 때, 수신 컴퓨터 시스템은 첨부 파일을 보다 지능적으로 처리할 수 있다. 예컨대, 컴퓨터 시스템은 스키마화된 첨부 파일의 필드를 질문할 수 있고 필드에 저장된 값에 따라 스키마화된 첨부 파일을 처리할 수 있다.
또한, 메시지 스키마(152)에 따라 정의된 메시지 아이템은 계정 스키마(158)에 따라 정의된 계정 관련 데이터를 참조 또는 링크할 수 있다. 메시지 아이템의 내용(예컨대, 메시지 본문 또는 메시지 첨부 파일)은 내용 스키마(156)에 따라 정의된 데이터 필드를 포함할 수 있다.
스키마(152)에 따라 정의된 메시지 아이템은 또한 하나 이상의 메시지 확장 스키마에 따라 정의된 데이터 필드를 포함할 수 있다. 일부 메시지 확장 스키마는 지정된 메시지 프로토콜과의 호환을 촉진시키는 프로토콜 확장자일 수 있다. 예컨대, 메시지 프로토콜 확장 스키마(161)는 특별한 메시지 프로토콜에 특정된 데이터 필드를 정의하는 하나 이상의 메시지 프로토콜 확장 스키마를 포함할 수 있다. 예 컨대, 프로토콜 확장 스키마(162)는 제1 메시지 프로토콜(예컨대, NTTP(Network News Transfer Protocol))에 특정된 하나 이상의 데이터 필드에 대한 데이터 포맷을 정의할 수 있고, 프로토콜 확장 스키마(163)는 제2 메시지 프로토콜(예컨대, POP3(Post Office Protocol 3)에 특정된 하나 이상의 데이터 필드의 데이터 포맷을 정의할 수 있다. 프로토콜 확장 스키마는 계층구조로 배열될 수 있다. 예컨대, 프로토콜 확장 스키마(164)는 (프로토콜 확장 스키마(162)에 따라 정의된 데이터 필드를 갖는) 제1 메시지 프로토콜의 특별한 구현에 특정된 추가적인 데이터 필드의 데이터 포맷을 정의할 수 있다.
다른 메시지 확장자는 지정된 메시지 애플리케이션과의 호환을 촉진시키는 애플리케이션 확장자일 수 있다. 예컨대, 메시지 애플리케이션 확장 스키마(166)는 메시지 애플리케이션에 특정된 데이터 필드를 정의하는 하나 이상의 메시지 애플리케이션 확장 스키마를 포함할 수 있다. 예컨대, 애플리케이션 확장 스키마(167)는 제1 메시지 애플리케이션(예컨대, 전자 우편 애플리케이션)에 특정된 하나 이상의 데이터 필드의 데이타 포맷을 정의할 수 있고, 애플리케이션 확장 프로토콜 스키마(168)는 제2 메시지 애플리케이션(예컨대, 팩스 애플리케이션)에 특정된 하나 이상의 데이터 필드의 데이터 포맷을 정의할 수 있다. 애플리케이션 확장 스키마는 계층구조로 배열될 수 있다. 예컨대, 애플리케이션 확장 스키마(169)는 (애플리케이션 확장 스키마(168)에 따라 정의된 데이터 필드를 갖는) 제2 메시지 애플리케이션의 특별 버전에 특정된 추가적인 데이터 필드의 데이터 포맷을 정의할 수 있다.
따라서, 메시지 스키마(152)에 따라 정의된 데이터 필드를 갖는 메시지 아이템은 또한, 메시지 프로토콜 확장 스키마(161) 및 메시지 애플리케이션 확장 스키마(166) 내의 확장 스키마에 따라 정의된 추가적인 데이터 필드를 가질 수 있다. 메시지 확장자에 대응하는 데이터 필드는 기존의 메시지 프로토콜 및 메시지 애플리케이션과의 호환을 용이하게 하기에 적절한 메시지 아이템 상에 "스냅"될 수 있고 그 메시지 아이템으로부터 제거될 수 있다. 따라서, 메시지 아이템에 포함된 데이터 필드의 구성은 시간에 따라 변화할 수 있다.
예컨대, 메시지 애플리케이션(111) 또는 메시지 애플리케이션(103)과 같은 애플리케이션은 특별한 프로토콜 확장 스키마 또는 애플리케이션 확장 스키마의 데이터 필드가 메시지 아이템을 액세스하기 전에 메시지 아이템에 스냅되거나 메시지 아이템으로부터 제거될 것을 요구할 수 있다. 따라서, 메시지 아이템은 특별한 메시지 프로토콜 또는 메시지 애플리케이션과의 호환을 위해 변환될 수 있다. 예컨대, 메시지 애플리케이션(103)은 NNTP 프로토콜 확장 스키마의 필드가 메시지 아이템(116)에 스냅될 것을 요구할 수 있다. 따라서, 메시지 애플리케이션(103)은 메시지 아이템(116)을 검색하여 NNTP 프로토콜과의 호환을 촉진하는 데이터 필드(예컨대, 프로토콜 확장 스키마(162)에 따라 정의된 것)를 포함하도록 메시지 아이템(116)을 변환한다. 변환된 메시지 아이템(예컨대, 메시지 아이템(107))은 컴퓨터 시스템(102)으로 전송될 수 있다.
메시지 애플리케이션(111)은 메시지 확장 스키마에 대응하는 새롭게 추가된 데이터 필드 하나 이상의 값을 파퓰레이팅하기 위해 하나 이상의 현재 할당된 데이 터 필드로부터 값을 자동 검색할 수 있다. 값의 검색은 스키마 계층구조(150) 내의 다른 스키마에 따라 정의된 정보를 참조 및 그에 링크하는 것을 포함할 수 있다. 예컨대, 메시지 애플리케이션(111)은 현재 할당된 팩스 확장자 전화 번호 필드로부터 전화번호를 검색하고, 콘택 사일로(182)로부터 전화 번호에 대응하는 콘택을 식별하고, 콘택 사일로(182)로부터의 콘택의 전자 우편 주소를 검색하고, 전자 우편 주소를 새롭게 할당된 전자 우편 메시지 "From:" 필드로 파퓰레이팅할 수 있다. 대안적으로, 사용자는 메시지 확장에 대응하는 새롭게 추가된 데이터 필드를 파퓰레이팅하기 위한 값을 입력하도록 재촉될 수 있다.
도 2A 내지 도 2D는 본 발명의 원리에 따라 보다 상세한 스키마 계층구조(200)의 예를 나타낸다. 도 2A에 도시된 바와 같이, 스키마 계층구조(200)는 기본 아이템 스키마(210)를 포함한다. 기본 아이템 스키마(210)는 기본 아이템 데이터를 나타내기 위한 데이터 포맷을 정의하는 상관 필드(211)를 포함한다. 특히, 상관 필드(211)는 표 1에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
ItemlD |
GUID |
데이터베이스 아이템의 글로벌 고유 식별자를 나타내기 위한 포맷을 정의함. |
Created |
DateTime |
ItemID 필드에 따라 정의된 글로벌 고유 식별자를 갖는 데이터베이스 아이템의 날짜 및 시간을 나타내기 위한 포맷을 정의함. |
DisplayName |
String |
아이템ID에 따라 정의된 글로벌 고유 식별자를 갖는 데이터베이스 아이템의 기술명을 나타내는 포맷을 정의함. |
도 2A에 도시된 바와 같이, 스키마 계층구조(200)는 메시지 스키마(212)를 포함한다. 메시지 스키마(212)는 기본 아이템 스키마(210)로부터 도출되고 또한 메시지 아이템을 나타내는 데이터 포맷을 정의하는 상관 필드(213)를 포함한다. 메시지 스키마(212)의 필드는 기본 아이템이 메시지 아이템의 속성을 나타낼 수 있도록 (기본 아이템 스키마(210)에 정의된) 글로벌 고유 식별자를 갖는 기본 아이템에 적용될 수 있다. 특히, 상관 필드(213)는 표 2에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
ContentLocation |
String |
메시지의 내용-위치 헤더로부터의 참조된 내용을 나타내기 위한 포맷을 정의함. 이 필드는 기본 내용 위치와 함께 사용될 수 있음. 일부 첨부 파일들은 이 내용-위치에 상대적인 내용-위치를 갖게 됨. |
DeferredSend Time |
DateTime |
메시지를 전송해야 하는 날짜 및 시간을 나타내는 포맷을 정의함. |
DeleteAfter Submnit |
Boolean |
메시지가 전달을 위해 제출된 후 삭제되어야 하는지를 나타내기 위한 포맷을 정의함. |
DownloadState |
String |
서버로부터 메시지를 다운로드하는 상이한 국면들을 나타내기 위한 포맷을 정의함. 부분 등. |
ExpiryDate |
DateTime |
메시지의 내용이 끝날 때, 날짜 및 시간을 나타내기 위한 포맷을 정의함. 일반적으로, 자동 동작은 내포되지 않음. |
Importance |
Int16 |
포맷 메시지 중요도의 메시지 송신자의 옵션을 나타내기 위한 포맷을 정의함. SMTP내의 "Importance:" 필드와 일치함. 가능한 값은 1("Low"), 2("Normal"), 및 3 ("High")임. 새로운 메시지에 대한 디폴트 값은 2 ("Normal")임. |
IsEncrypted |
Boolean |
메시지가 암호화되었는지를 나타내기 위한 포맷을 정의함. |
IsRead |
Boolean |
메시지가 사용자에 의해 읽힌 것으로 마킹되었는지를 나타내기 위한 포맷을 정의함. |
IsSigned |
Boolean |
메시지가 사인되었는지를 나타내기 위한 포맷을 정의함. |
LastActionTaken |
String |
메시지에 대해 취해진 최종 동작을 나타내기 위한 포맷을 정의함. 가능한 값은 응답완료(Replied) 및 전송완료(Forwarded)임. |
LastActionTime |
DateTime |
최종 동작이 메시지에 대해 취해진 날짜 및 시간을 나타내기 위한 포맷을 정의함. |
LastActionType |
String |
이 메시지에 대해 취해진 최종 동작의 타입을 나타내기 위한 포맷을 정의함. LastActionTaken과 함께 해석되어야 함. 예를 들면, 팩스 또는 전자 우편으로 응답하였음을 표시하기 위한 팩스 또는 전자 우편을 들 수 있음. |
NormalizedSubject |
String |
메시지 표준화된 주제를 나타내기 위한 포맷을 정의함. NormalizedSubject는 프리픽스 후의 주제의 부분임. 프리픽스가 없으면, NormalizedSubject는 주제와 동일함. |
Preview |
String |
메시지의 미리보기를 나타내기 위한 포맷을 정의함. 미리보기 속성은 메인 메시지 본문의 제 1의 적은 문자, 또는 메시지를 미리보기 위하여 사용되는 일부 표현을 포함할 수 있음. 이는 캐시 최적화 필드임. 이는 본문으로부터 계산되어 미리 보기 시나리오에서의 고속 검색을 위해 여기에 놓임. 이는 텍스트만을 포함하는 필드이고 필수적인 것임. |
PrimaryType |
String |
메시지에 연관된 메시지 타입(예컨대, 전자 우편, 팩스메시지, 인스턴트메시지, 음성메시지, 모임 요청 등)을 나타내기 위한 포맷을 정의함. 메시지 타입은 메시지의 행위를 내포함. 애플리케이션은 메시지의 타입에 기초하여 아이콘을 사용자 지정할 수 있고 사용자 지정 헤더를 판독할 수 있음. 이 값은 X-메시지타입 헤더로부터 얻어질 수 있음. |
Priority |
Int16 |
메시지에 대해 메시지 우선 순위를 나타내기 위한 포맷을 정의함. 애플리케이션에 의해 설정되는 전달을 위한 메시지 우선 순위임. 값은 AboveNormal=2, Normal=2, BelowNormal=1임. 보다 높은 값은 전송이 하위 레벨의 메시지보다 빨리 메시지를 전달해야 함을 나타냄. |
ReadReceipt Requested |
Boolean |
판독 수신이 이 메시지에 대해 요청되었는지를 나타내기 위한 포맷을 정의함. |
SendStatus |
String |
메시지의 전송상태를 나타내기 위한 포맷을 정의함. "받는사람": 전송이 픽업하는 방식으로 UI 마크를 구성함. "전송하기": 전송은 "받는사람"에서 "전송하기"로 천이되어, 다른 전송은 메시지를 시도하지 않게 됨. "전송완료": 전송이 완료된 후 전송은 "전송하기"에서 "전송완료"로 천이됨. |
Sensitivity |
String |
메시지의 민감도의 메시지 송신자의 옵션을 나타내는 포맷을 정의함. SMTP의 "민감도:" 필드와 대응됨. 가능한 값은 없음(특별한 민감도가 없음), 개인적임, 사적임, 또는 회사 기밀임이다. 새로운 메시지에 대한 디폴트값은 없음임. |
Size |
Int64 |
메시지의 계산된 바이트 크기를 나타내기 위한 포맷을 정의함. 이는 본문, 헤더 및 첨부 파일을 갖는 전체 메시지를 포함함. 값은 크기가 알려지지 않은 경우 손실될 수 있음. |
Subject |
String |
메시지의 주제를 나타내기 위한 포맷을 정의함. 예컨대, 메시지의 토픽을 기술하는 하나의 라인임. 이 필드 NormalizedSubject 및 SubjectPrefix로부터 계산됨. 메시지의 주제임. 주제는 다음의 방식으로 Subject 및 SubjectPrefix 값으로부터 계산될 수 있음: (1) ubjectPrefix가 존재하면, Subject는 프리픽스를 갖는NormalizedSubject의 내용으로 설정됨. (2)SubjectPrefix 가 존재하지 않으면, NormalizedSubject는 Subject로 복사됨. |
SubjectPrefix |
String |
메시지의 SubjectPrefix를 나타내기 위한 포맷을 정의함. 하나 이상의 영문숫자 문자와 후속되는 콜론 및 스페이스(프리픽스의 일부)로 구성됨. 주제 프리픽스는 없을 수 있음. SubjectPrefix가 명확하게 설정되면, 이는 길이를 가질 수 있고 영문숫자 문자를 이용할 수 있으며,주제의 시작 부분의 서브스트링과 일치할 수 있음. SubjectPrefix가 명확하게 설정되지 않고 계산되어야 한다면, 그 내용은 더욱 제한될 수 있음. 프리픽스를 계산하기위한 하나의 가능한 규칙은 주제가 1개, 2개, 또는 3개의 문자(영문자만)와 후속되는 콜론 및 스페이스로 시작되는 것임. 이러한 서브스트링이 주제의 시작부분에서 발견되면, SubjectPrefix가 됨(또한, Subject 필드의 시작 부분에 머뭄). 그렇지 않으면, SubjectPrefix는 미설정 상태로 머뭄. |
TimeDownloaded |
DataTime |
서버로부터 메시지가 다운로드된 날짜와 시간을 나타내는 포맷을 정의함. |
TimeReceived |
DateTime |
메시지가 다운로드된 날짜 및 시간을 나타내기 위한 포맷을 정의함. TimeReceived는 메시지가 서버로부터 다운로드되어 로컬 스토어에 저장된 시간보다는 메시지가 서버에 의해 전달된 시간을 적절히 기술함. 이 값은 드래프트 메시지 상에서 생략될 수 있고 및 전송 메시지의 복사로 보존됨. |
TimeSent |
DateTime |
메시지 송신자가 메시지를 제출한 날짜 및 시간을 나타내기 위한 포맷을 정의함. 드래프트 메시지에서는, 이 값이 생략될 수 있음. 메시지가 제출될 때 설정될 수 있음. |
Attachment Message |
Attachment |
메시지에 대응 첨부 파일 데이터로의 링크를 나타내기 위한 포맷을 정의함. 첨부 파일 데이터는 첨부 파일 스키마에 따라 정의될 수 있음. |
MessageConents |
ContentsData |
메시지에 대응하는 메시지 내용의 부분으로의 링크를 나타내기 위한 포맷을 정의함. 메시지 내용의 부분은 내용 스키마에 따라 정의될 수 있음. |
MessageOriginal DeliveryAccount |
OriginalDelivery AccountData |
메시지에 대응하는 원래 전달 계정 데이터로의 링크를 나타내기 위한 포맷을 정의함. 원래 전달 계정 데이터는 계정 스키마에 따라 정의될 수 있음. |
Message Participants |
ParticipantsData |
링크 메시지에 대응하는 콘택 데이터로의 링크를 나타내기 위한 포맷을 정의함. 콘택 데이터는 콘택 스키마에 따라 정의될 수 있음. 콘택 데이터는 메시지 교환에 참여한 사용자의 컬렉션을 나타낼 수 있음. 이는 송신자, 수신자, Cc(people copied) 등을 포함함. 참가자는 메시지 송신자/수신자를 나타내는 콘택 아이템으로의 링크임. 이 타입의 필드가 참가자에 관한 모든 필요한 데이터를 포함하는 경우 댕글링으로 유지될 수 있음. |
MessageSentMes sageFolder |
SentMessage FolderData |
메시지에 대응하는 폴더 아이템으로의 링크를 나타내기위한 포맷을 정의함. 폴더 아이템은 폴더 스키마에 따라 정의될 수 있음. 이 필드는 메시지가 전달을 위해 제출된 후 이동될 수 있는 폴더로의 링크를 지정함. |
도 2A에 도시된 바와 같이, 스키마 계층구조(200)는 콘택 스키마(214)를 포함한다. 콘택 스키마(214)는 콘택 아이템을 나타내기 위한 데이터 포맷을 정의하는 상관 필드(215)를 포함한다. 메시지 스키마(212)에 따라 정의된 메시지 아이템은 콘택 스키마(214)에 따라 정의된 콘택 아이템으로의 링크를 포함할 수 있다. 참가자는 메시지 송신자, 수신자 등을 나타내는 콘택 아이템으로의 링크일 수 있다. 참가자 링크는 댕글링(dangling)으로 머물 수 있고, 이 경우 이 타입에 관한 필드는 참가자에 관해서 모든 필요한 데이터를 포함한다. 특히, 상관 필드(215)는 표 3에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
EAddress |
EAddress |
메시지 참가자에 대응하는 하나 이상의 전자 주소를 표현하는 포맷을 정의함. 이 필드는 메시지 참가자(예컨대, 메시지 스키마에 따라 정의된 메시지)의 전자 주소를 나타낼 수 있음. 이는 사용자명 및 주소 정보를 위해 사용됨. 이는 사적인 DL 경우에 생략될 수 있음. 이는 레거시 DN 경우를 위해 다수 값을 가짐. 콘택은 다수의 EAddress 필드를 포함할 수 있음. |
GroupID |
GUID |
참가자 그룹 식별자를 나타내기 위한 포맷을 정의함. 이 필드는 RFC 2822 수신자 그룹 신택스를 지원할 수 있음. 이는 동일명을 갖는 2 개의 그룹의 처리를 포함해서 특정 디스플레이명으로 수신자들을 그룹화하는 방법임. |
Order |
Int32 |
참가자에 해당하는 순서를 나타내기 위한 포맷을 정의함. 사용자 인터페이스는 참가자의 순서를 사용자에 디스플레이해 줄 때 이 값을 고려할 수 있음. |
Type |
String |
참가자(개인, 조직, 및 회사)에 대응하는 엔터티의 타입을 나타내기 위한 포맷을 정의함. 이는 사람들이 다른 값을 여기에 추가할 수 있는 자유 형태임. |
Usage |
String |
메시지의 참가자 이용을 나타내기 위한 포맷을 정의함. 가능한 값은 From, To, Cc, Bee, Sender, ReplyTo, ReceivedRepresenting, TransportSender임. 이는 또한 다른 값을 포함할 수 있음. 애플리케이션은 이 필드의 모든 종류의 값을 이해할 필요가 없음. 일부는 전자 우편에만 적용되고, 일부는 IM 메시지 등에 적용됨. |
DeliveryReceipt Request |
Boolean |
전달 수신이 참가자에 요청되었는지를 나타내는 포맷을 정의함. |
도 2A에 도시된 바와 같이, 스키마 계층구조(200)는 폴더 스키마(220)를 포함한다. 폴더 스키마(220)는 폴더 아이템을 나타내기 위한 데이터 포맷을 정의하는 상관 필드(221)를 포함한다. 메시지 스키마(212)에 따라 정의된 메시지 아이템은 폴더 스키마(220)에 따라 정의된 폴더로의 링크를 포함할 수 있다. 특히, 상관 필드(221)는 표 4에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
CanCreateChildren |
Boolean |
폴더가 자식 폴더를 포함할 수 있는지를 나타내기 위한 포맷을 정의함. 서버는 폴더가 자식 폴더를 갖는 것을 원하지 않거나 허락하지 않을 수 있음. IMAP는 IMAP LIST 응답의 지명된 속성의'\Noinferiors'를 반환함으로써 이를 나타냄. |
CustomType |
String |
폴더에 대응하는 사용자 지정 타입을 나타내기 위 한 포맷을 정의함. 이는 폴더의 타입을 고유하게 식별하는 GVID 또는 다른 사용자 지정 타입을 포함함. 이는 "SpecialOffers", "Errors", "PreProcessing" 또는 타입 카테고리에 추가되도록 빈번하게 발생하는 다른 사용자 지정 폴더 지시자를 위해 사용될 수 있음. |
Description |
String |
폴더의 설명을 나타내기 위한 포맷을 정의함. |
DisplayName |
String |
폴더의 디스플레이명을 나타내기 위한 포맷을 정의함. 폴더명은 피어들 사이에서 고유할 수 있으나 DisplayName는 고유할 것을 요구하기 위해 데이터베이스를 갖지 않음. |
Size |
Int64 |
폴더의 계산된 바이트 크기를 나타내기 위한 포맷을 정의함. 이는 폴더 내의 메시지의 전체 본문, 헤더 및 첨부 파일을 포함할 수 있음. 크기가 알려지지 않은 경우 값은 생략될 수 있음 |
SynchronizationType |
String |
폴더가 동기화되는 법을 나타내기 위한 포맷을 정의함. IMAP, NNTP, 및 DAV 계정을 위해 가장 빈번하게 사용됨. 값 다음과 같다: All; 폴더를 완전히 동기화함, 헤더; 헤더를 동기화함, New; 새로운 아이템을 동기화함. |
TotalCount |
Int32 |
폴더 내의 메시지의 전체 수를 나타내기 위한 포맷을 정의함. |
Type |
String |
일부 폴더가 특수 방법으로 처리될 수 있으므로 특수 지정을 나타내기 위한 포맷을 정의함. 예컨대, RemoteRoot은 하나 이상의 InboxPrimary를 가져서는 안됨. 그러나, 이는 하나 이상의 Inbox를 가질 수 있음. 값은 다음과 같다[이들은 전자 우편 계정의 루트인 폴더에 맴핑될 수 있음] 1) RemoteRoot; 이 폴더 및 그 칠드런은 서버(예: IMAP)로부터 폴더 및 메시지를 미러 처리하는 계정에 1대1로 맵핑됨, 2) LocalRoot: 서버로부터 폴더 및 메시지를 미러 처리하는 계정에 1대1로 맵핑되지 않는 폴더 [이들은 전자 우편 계정의 루트인 폴더에 맵핑될 수 있음] 3) Inbox; 이 폴더는 "Inbox"로 지정됨. 4) Outbox; 이 폴더는 "Outbox"로서 지정됨. 5) Sent: 이 폴더는 "Sent"로서 지정됨. 6) Deleted: 이 폴더는 "Deleted"로서 지정됨. 7) Drafts: 이 폴더는 "Drafts"로서 지정됨, 8) Junk: 이 폴더는 "Junk"로서 지정됨. |
UnreadCount |
Int32 |
폴더 내의 읽지 않은 메시지의 개수를 나타내기 위한 포맷을 정의함. 이는 이 폴더 내의 메시지 아이템만을 설명함. |
Account |
AccountData |
계정 데이터로의 링크를 나타내기 위한 포맷을 정의함. 계정 데이터는 정의된 계정 스키마에 따라 정의될 수 있음. |
도 2A에 도시된 바와 같이, 스키마 계층구조(200)는 내용 스키마(216)를 포함한다. 내용 스키마(216)는 메시지 아이템에 연관된 내용의 부분을 나타내기 위한 데이터 포맷을 정의하는 상관 필드(217)를 포함한다. 메시지 스키마(212)에 따라 정의된 메시지 아이템은 내용 스키마(216)에 따라 정의된 내용(예컨대, 본문 또는 첨부 파일)의 부분에 링크를 포함할 수 있다. 이는 문서, 이벤트, 또는 콘텐트의 일부 다른 부분으로의 링크일 수 있다. 메시지 아이템은 다수의 본문(body) 및/또는 첨부 파일을 가질 수 있다. 예컨대, 멀티파트 MIME 메시지는 다수의 본문을 포함할 수 있다. 특히, 상관 필드(217)는 표 5에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
ContentMetadata |
ContentProperties |
내용의 일부의 내용 속성(예컨대, 메시지 본문 또는 첨부 파일)을 나타내기 위한 포맷을 정의함. 내용 속성 타입은 메시지의 내용을 기술하는 필드를 포함함. 이는 첨부 파일의 확장자의 내용을 나타내는 메시지와 아이템 간의 관계에 있음. |
IsAttachment |
Boolean |
참조된 내용 부분이 본문인지 아니면 메시지의 첨부 파일인지를 나타내기 위한 포맷을 정의함. 이 필드는 MIME로부터의 제안인 ContentDisposition 필드와는 반대로 애플리케이션이 이 내용을 무엇이라고 생각하는지를 나타냄. |
Order |
Int32 |
내용 부분의 순서를 나타내기 위한 포맷을 정의함. 이 값은 본문 및 첨부 파일의 순서를 제공함. 사용자 인터페이스는 첨부 파일의 순서를 사용자에게 디스플레이할 때 이 값을 고려해야 함. 제 1 본문은 선호되는 것일 수 있음. |
도 2A에 도시된 바와 같이, 스키마 계층구조(200)는 첨부 파일 스키마(218)를 포함한다. 첨부 파일 스키마(218)는 메시지 아이템에 연관된 첨부 파일을 나타내기 위한 데이터 포맷을 정의하는 상관 필드(219)를 포함한다. 첨부 파일 스키마(218)에 따라 정의된 첨부 파일은 메시지 스키마(212)에 따라 정의된 메시지 아이템으로의 링크를 포함할 수 있다. 특히, 상관 필드(219)는 표 6에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터타입 |
필드 설명 |
ContentMetadata |
ContentProperties |
첨부 파일의 내용 속성을 나타내기 위한 포맷을 정의함. 내용 속성 타입은 필드는 첨부 파일을 기술하는 필드를 포함함. 첨부 파일의 확장자에 관한 내용을 나타내는 메시지와 아이템 간의 관계에 있음. |
AttachmentState |
String |
첨부 파일의 타입 및 행동을 나타내기 위한 포맷을 정의함. 값은 다음을 포함함: 1) EnclosedAttachment: 이 값은 Mime의 외부에서 디코딩되어 저장된 첨부 파일을 나타냄. 첨부 파일은 Mime Stream내에 동봉된 것처럼 행동하게 됨. 이 데이터베이스 아이템은 데이터가 디코딩 형태로 저장되어야 하고 속성은 스키마화되어야 하기 때문에 생성되었음. 이를 필요로 하는 2 개의 가장 일반적인 시나리오는 다음과 같다: A. 일부 프로토콜은 MIME 내용 밖의 첨부 파일을 디코딩된 형태로 다운로드 함. B. 첨부파일 데이터 또는 메타 속성은 액세스 가능해야 하나, 이 첨부 파일은 수신자가 바로 사용할 수 있도록 송신자가 문서/파일을 첨부한 것처럼 행동할 수 없음. Signature blob, Inline Only 첨부 파일, Digital Signature certs 또는 데이터를 예로 들 수 있음. 2) PromotedAttachment: 이 첨부 파일은 메시지의 피어처럼 동작하도록 됨. 메시지와 함께 셸내에 나타나게 됨. 3) SavedAsAttachment: 이 첨부 파일은 '로서 저장하기'이며, 따라서 메시지의 복사하기로서 작용함. |
IsEncrypted |
Boolean |
첨부 파일이 암호화되었는지를 나타내기 위한 포맷을 정의함. |
IsPinned |
Boolean |
첨부 파일이 고정되었는지를 나타내기 위한 포맷을 정의함. 상기 고정은 메시지가 삭제될 때에도 계속 존재하게 됨을 의미함. 첨부 파일이 고정되어 있지 않으면, 다음의 동작일 일어남: 1. 메시지가 삭제될 때, 첨부 파일도 삭제됨. 2. 첨부 파일 아이템이 삭제될 때, 첨부 파일에 연관 된 정보 또는 메타데이터가 메시지로부터 삭제됨(공간을 절약하기 위해 또는 프라이버시를 위해) |
IsRead |
Boolean |
첨부파일에 링크된 메시지가 사용자에 의해 읽힌 것으로 마킹되었는지를 나타내기 위한 포맷을 정의함. |
IsSigned |
Boolean |
첨부파일에 링크된 메시지가 사인되었는지를 나타내기위한 포맷을 정의함. |
IsTrusted |
Boolean |
다른 파일과 함께 나타나도록 첨부 파일에 링크된 메시지가 사용자의 보안 선호도를 만족하는지를 나타내기 위한 포맷을 정의함. 보안 선호도가 만족되면, 첨부 파일이 경고 사용자 인터페이스를 디스플레이할 필요가 없도록 사용자의 기준을 만족함. 상기 기준은 사용자가 승인한 첨부 파일 내용 또는 이미 디스플레이된 사용자 인터페이스일 수 있음. 반면에, 보안 선호도가 만족되지 않으면, 보안 선호도를 경고하는 사용자 인터페이스가 첨부파일이 열리기 전에 사용자에게 보여져야 함. 이는 내용이 신뢰할 수 없는 소스로부터 온 것이고 해로운 내용을 포함할 수 있음을 사용자에게 알림. |
LastActionTaken |
String |
첨부 파일에 링크된 메시지에 대해 취해진 최종 동작을 나타내기 위한 포맷을 정의함. 가능한 값은 응답완료(Replied) 및 전송완료(Forwarded)임. |
LastActionTime |
DateTime |
첨부 파일에 링크된 메시지에 대해 취해진 최종 동작의 날짜 및 시간을 나타내기 위한 포맷을 정의함. |
LastActionType |
String |
첨부 파일에 링크된 메시지에 대해 취해진 최종 동작의 타입을 나타내기 위한 포맷을 정의함. LastActionTaken과 함께 해석되어야 함. 예: 팩스 또는 전자 우편으로 응답하였다는 표시를 하기 위한 팩스 또는 전자 우편. |
Priority |
String |
첨부 파일 링크된 메시지의 우선순위를 나타내기 위한 포맷을 정의함. 첨부 파일 전달 우선순위는 애플리케이션에 의해 설정될 수 있음. 가능한 값음 AboveNormal, Normal, BelowNormal임. 보다 높은 값은 전송이 하위 레벨의 아이템보다 빨리 첨부 파일을 전송해야 함을 나타냄. |
SendStatus |
String |
첨부 파일의 전송 상태를 나타내기 위한 포맷을 정의함. 예컨대, VI는 전송이 픽업하도록 첨부 파일 "받는 사람"을 표시함. VI는 첨부 파일을 "받는 사람"로부터 "송신중"으로의 전이를 나타내는 "송신중"으로서 표시할 수 있으며, 따라서다른 전송은 메시지 전송을 시도하지 않게 됨. VI는 첨부 파일을 "송신 완료"로 표시할 수 있고, 전송은 전송 완료 후 "송신중" 으로부터 "송신 완료"로 전이됨. |
Size |
Int64 |
첨부 파일에 링크된 메시지(첨부 파일 포함)의 크기를 나타내기 위한 포맷을 정의함. |
Subject |
String |
첨부 파일에 링크된 메시지의 주제를 나타내기 위한 포맷을 정의함. 예컨대, 첨부 파일을 기술하는 한 줄임. |
TimeReceived |
DateTime |
첨부 파일이 전달된 날짜 및 시간을 나타내기 위한 포맷을 정의함. TimeReceived 속성은 첨부 파일이 서버로부터 다운로드되어 로컬 데이터베이스 스토어에 저장된 시간보다는 첨부 파일에 링크된 메시지가 서버에 의해 수신된 시간을 기술함. 이 값은 드래프트 메시지에서 생략될 수 있고, 전송 메시지의 복사로서 유지됨. |
TimeSent |
DateTime |
첨부 파일에 링크된 메시지가 제출된 날짜 및 시간을 나타내기 위한 포맷을 정의함. 드래프트 메시지에서 이 값은 손실될 수 있고, 메시지가 제출될 때 설정되게 됨. |
Type |
String |
첨부 파일에 링크된 메시지의 타입을 나타내기 위한 포맷을 정의함. 타입은 링크된 메시지의 행동을 내포함. 애플리케이션은 타입에 기초하여 아이콘을 사용자 지정하고 사용자 지정 헤더를 판독함. 이 값은 X-메시지타입 헤더로부터 얻을 수 있음. |
Attachment Message |
MessageData |
첨부 파일과 연결된 메시지 아이템에의 링크를 나타내기 위한 포맷을 정의함. 메시지 아이템은 메시지 스키마에 따라 정의될 수 있음. |
Attachment Participants |
ParticipantsData |
첨부 파일에 링크된 메시지의 교환에 참여한 사용자의 컬렉션을 나타내기 위한 포맷을 정의함. 이는 송신자, 수신자, Cc(people copied) 등을 포함함. |
AttachmentSaved From |
SavedFromData |
첨부 파일이 저장된 할당에의 링크를 나타내기 위한 포맷을 정의함. 사용자는 첨부 파일로서 저장하기 위해 사용자 인터페이스를 이용할 수 있음. 이와 같이 함으로써, 첨부 파일이 복사됨. 이 값이 포함되면, 첨부 파일은 원래 첨부 파일의 '로서 저장하기' 복사본임. 이 링크의 목적지는 원래 첨부 파일임. |
AttachmentSource |
AttachmentSource Data |
첨부 파일의 소스를 을 나타내기 위한 포맷을 정의함. 첨부 파일이 구성되고 이 링크가 값을 가지면, 링크는 첨부 파일이 얻어지는 데이터베이스 아이템을 가리킴. |
도 2A에 도시된 바와 같이, 스키마 계층구조(200)는 계정 스키마(222)를 포함한다. 계정 스키마(222)는 계정 아이템을 나타내기 위한 데이터 포맷을 정의하는 상관 필드(223)를 포함한다. 메시지 스키마(212)에 따라 정의된 메시지 아이템(또는 폴더 스키마(220)에 따라 정의된 폴더 아이템)은 계정 스키마(219)에 따라 정의된 계정 아이템으로의 링크를 포함할 수 있다. 계정 아이템은 메시지 계정 및 설정값을 포함할 수 있다. 특히, 상관 필드(223)는 표 7에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
Address |
Eaddress |
이 계정에 매핑되는 하나 이상의 전자 주소를 나타내기 위한 포맷을 정의함. 이 컬렉션 순서를 가져야 하며 이 순서는 중요함. 제 1 전자 주소는 (From 필드 파퓰레이션에 사용되는) 메인 주소임. |
Description |
String |
계정에 관한 설명을 나타내기 위한 포맷을 정의함. |
IncomingServerAccount |
SeverAccount |
계정의 메시지를 수신할 수 있는 서버를 나타내기 위한 포맷을 정의함. (쌍방향 서버는 받는 계정 및 보내는 계정 내의 정보를 복제해야 함). |
Organiztion |
String |
계정과 연관된 구조를 나타내기 위한 포맷을 정의함. |
OutogingServerAccount |
ServerAccount |
계정의 메시지를 보낼 수 있는 서버를 나타내기 위한 포맷을 정의함. 쌍방향 서버는 수신 계정 및 송신 계정 내의 정보를 복제해야 함. |
Synchronize |
Boolean |
계정이 서버와 동기화되어야 하는지를 나타내기 위한 포맷을 정의함. 사용자가 특별히 요청하지 않는 한, 사용자는 계정 동기화를 스킵하기를 원할 수 있음. |
FolderAccount |
Folder |
이 계정을 가리키는 폴더 아이템에의 링크를 나타내기 위한 포맷을 정의함. 폴더 아이템은 폴더 스키마에 따라 정의될 수 있음. |
도 2B에 도시된 바와 같이, 스키마 계층구조(200)는 내용 속성 스키마(224)를 포함한다. 내용 속성 스키마(224)는 내용 속성을 나타내기 위한 데이터 포맷을 정의하는 상관 필드(225)를 포함한다. 내용 속성은 메시지의 내용을 기술하는 필드를 포함한다. 내용 속성 메시지 아이템과 (예컨대, 내용 스키마(216)에 따라 정의된) 내용 부분 사이의 관계에 또는 (예컨대, 첨부 파일 스키마(218)에 따라 정의된) 첨부 파일의 확장자에 이용된다. 특히, 상관 필드(225)는 표 8에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
ContentBase |
String |
내용의 내용 베이스를 나타내기 위한 포맷을 정의함. ContentID, ConteentBase, 및 ContentLocation를 이용하면 MIME 부들간을 참조할 수 있음. 이는 HTML 본문의 URL이 첨부 파일된 내용을 참조하도록 하는데 이용될 수 있음. |
ContentDescription |
String |
내용을 수반할 수 있는 설명을 나타내기 위한 포맷을 정의함. 전자 우편 메시지의 경우, 이 값은 may have come from 내용-설명:헤더로부터 얻을 수 있음. 일부 레거시 클라이언트는 추천된 파일명의 내용 설명을 이용함. |
ContentID |
String |
내용의 내용 엔터티 ID를 나타내기 위한 포맷을 정의함. 내용-ID,내용-Base 및 내용-위치를 이용하면, MIME 부들간을 참조할 수 있음. 이는 HTML 본문의 URL이 첨부 파일된 내용을 참조하도록 하는데 이용될 수 있음. |
ContentTpye |
String |
내용의 내용 타입을 나타내기 위한 포맷을 정의함. 전자 우편 메시지의 경우, 이는 첨부 파일을 얻을 수 있는 MIME 부의 Content-Type 헤더 필드와 매칭될 수 있음. 다른 타입의 전자 메시지의 경우, 이 내용 타입은 내용의 내용과 가장 잘 매칭될 수 있음. 예컨대: Content-Type은 'audio/mp3'일 수 있고 메시지 내용은 뮤직 스키마내의 아이템 또는 뮤직 데이터를 포함하는 .mp3 파일 또는 뮤직 데이터를 저장하는 다른 아이템을 포인팅할 수 있음. 따라서, Content-Type은 데이터의 표준 지시를 제공함. 이는 자유로운 스트링 형태임. 애플리케이션은 '텍스트/html' 및 다른 mime 내용 타입이 아닌 자신의 타입을 이곳에 둠. |
ContentTypeParameters |
String |
Content-Type 헤더내의 파라미터를 나타내기 위한 포맷을 정의함. 파라미터는 '속성=값'의 포맷을 가지며, ';'에 의해 분리됨. 파일명을 포함할 수 있음. |
IsMacBinary |
Boolean |
첨부 파일이 Mac Binary인지를 나타내기 위한 포맷을 정의함. 이는 Mac binaries의 특수 처리를 용이하게 함. |
MimeURL |
String |
MIME 경로를 나타내기 위한 포맷을 정의함. MimePath: URL의 형태: MimePath:///[Levell]: [MuitiPart-Type]/[Leve12]:[MuitiPart-Type]/...I[Level n] : [MuitiPart-Type] |
SuggestedFileName |
String |
내용과 함께 가도록 추천된 파일명을 나타내기 위한 포맷을 정의함. 경로는 생략될 수 있고 파일명을 포함할 수 있음. 전자 우편 메시지의 경우, 이 값은 원래 전자 우편 메시지내의 Content-Type: 'name' 파라미터 또는 내용-Disposition-파일명 또는 다른 위치로부터 얻을 수 있음. 예컨대, 'Bill in Florida 2004.jpg' |
도 2B에 도시된 바와 같이, 스키마 계층구조(200)는 서버 계정 스키마(228)를 포함한다. 서버 계정 스키마(228)는 서버 계정을 나타내기 위한 데이터 포맷을 정의하는 상관 필드(229)를 포함한다. 서버 계정 스키마(228)에 따라 정의된 서버 계정 데이터는 특별한 서버와의 호환을 위해 (예컨대, 계정 스키마(222)에 따라 정의된) 계정을 확장할 수 있다. 서버 계정 스키마는 클라이언트 계정을 위해 서버 계정을 기술하는 데에 사용될 수 있다. 특히, 상관 필드(229)는 표 9에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드데이터 타입 |
필드 설명 |
AuthenticaitonMethod |
String |
서버 인증 방법을 나타내기 위한 포맷을 정의함. 이 컬렉션은 순수화되고 제1 엔트리가 선호되는 엔트리임. |
NetworkProtocol |
String |
서버로부터 송수신하는데 사용되는 프로토콜을 나타내기 위한 포맷을 정의함. 값은 POP3, IMAP, NNTP, DAV.Hotmail, DAV. Exchange 등임. |
PasswordIndexUUID |
String |
인덱스를 서버의 패스워드 스토어로 나타내기 위한 포맷을 정의함. 보안을 개선하기 위해, 패스워드는 패스워드 스토어의 데이터베이스의 외부에 저장될 수 있음. 이 UUID는 패스워드 스토어로의 인덱싱을 허용함. |
PortNumber |
Int32 |
서버를 콘택할 때 포트 번호를 나타내기 위한 포맷을 정의함. |
Server |
String |
서버를 지시하는 호스트명 또는 URL를 나타내기 위한 포맷을 정의함. |
SSLEnabled |
Boolean |
서버에 접속할 때 SSL을 사용해야 하는지를 나타내는 포맷을 정의함. |
UserName |
String |
서버에 로그인할 때 사용할 사용자명을 표현하는 포맷을 정의. |
도 2C에 도시된 바와 같이, 스키마 계층구조(200)는 메시지 프로토콜 확장 스키마(230) 및 메시지 애플리케이션 확장 스키마(250)를 포함하는 복수의 메시지 확장 스키마를 포함한다. 메시지 프로토콜 확장 스키마(230)는 복수의 대응 메시지 프로토콜과의 호환을 위해 메시지 아이템을 확장하는 데에 이용될 수 있는 복수의 프로토콜 확장 스키마를 포함한다. 예컨대, 메시지 프로토콜 확장 스키마(230)는 각각 인스턴트 메시지, 전자 우편, 및 팩스 프로토콜과의 호환을 촉진시킬 수 있는 인스턴트 메시지 프로토콜 스키마(231), 전자 우편 프로토콜 스키마(233), 및 팩스 프로토콜 스키마(235)를 포함한다. 메시지 프로토콜 확장 스키마(230)에 명확하게 나타낸 스키마 뒤, 사이 및 앞에 있는 생략부호는 메시지 프로토콜 확장 스키마(230)가 (예컨대, 음성 메시지 프로토콜, 블로그 엔트리 프로토콜 등과의 호환을 위해 메시지 아이템을 확장하기 위한) 추가적인 스키마를 포함할 수 있음을 나타낸다.
수직 생략부호(232 및 236)는, 인스턴트 메시지 프로토콜 스키마(231) 및 팩스 프로토콜 스키마(235)의 각각이 하나 이상의 상관 데이터 필드를 포함할 수 있음을 나타낸다. 하나 이상의 상관 데이터 필드는 대응 메시지 프로토콜과의 호환을 위한 메시지 아이템을 확장하는 데에 이용될 수 있다. 예컨대, 전자 우편 프로토콜 스키마(233)는 전자 우편 프로토콜과의 호환을 위해 (예컨대, 메시지 스키마(212)에 따라 정의된) 메시지 아이템을 확장하는 데에 이용될 수 있는 상관 필드(234)를 포함한다. 특히, 상관 필드(234)는 표 10에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드데이터타입 |
필드 설명 |
ConversationIndex |
Binary |
대화 쓰레드 내의 이 메시지의 상대 위치를 나타내기 위한 포맷을 정의함. ConversationIndex는 연결된 시간 스탬프 값을 이용하여 구현될 수 있음. 대화 뷰는 ConversationTopic에 의해 메시지 리스트를 그룹화하고 ConversationIndex에 의해 각각의 그룹 내에 소팅함으로써 생성됨. |
ConversationTopic |
String |
일련의 메시지 및 답변에 대응하는 대화 쓰레드를 나타내는 포맷을 정의함. ConversationTopic 값은 예컨대 NormalizedSubject에 대해 쓰레드 내의 제 1 메시지를 위해 설정됨. |
FlagColor |
String |
플래그의 색상을 나타내기 위한 포맷을 정의함. |
FlagReminderDate |
String |
요청된 동작이 예정된 날짜와 시간을 나타내기 위한 포맷을 정의함. |
FlagStatus |
String |
메시지가 사용자에 의해 플래그되었는지를 나타내기 위한 포맷을 정의함. 가능한 값은 없음, 마킹됨, 완전함을 포함한다. 이 분류는 애플리케이션 요건에 기초하여 확장될 수 있음. |
FlagTitle |
String |
메시지 상의 플래그의 텍스트를 나타내기 위한 포맷을 정의함. |
InternetMessageID |
String |
메시지의 인터넷 메시지 ID를 나타내기 위한 포맷을 정의함. SMTP 내의 RFC2822"Message-ID" 필드와 일치할 수 있음. 이 값은 새로 생성된 드래프트 메시지 상에서는 생략될 수 있음. |
MimeStream |
Binary |
메시지의 MIME 인코딩된 내용을 나타내기 위한 포맷을 정의함. MimeContent는 메시지 내용의 미해석 형태를 나타냄. 메시지 스트림이 분석되어 필드(메시지 타입, 본문, 첨부파일)로서 저장될 수 있음. 특정 종류의 드물게 사용되는 사용자 지정 정보가 특히 'X-'헤더, 일부 MIME 섹션 헤더, 텍스트 경계 전 또는 후, 리던던트 첨부 파일명(Content-Type:'Name', Content-Type-Disposition-Filename 등)과 같은 MimeStream 내에만 존재하게 됨. 원래 MimeStream은 디지털 서명을 체크하는데 사용될 수 있고 상이한 문자 세트로 디코딩 시도하는데 사용될 수 있음. 이 필드는 FileStream 타입을 가질 수 있음. |
ShowPaperClip |
Boolean |
메시지가 UI 내의 메시지의 페이퍼 클립을 보여주는 것을 인가하는 중요한 첨부 파일을 포함하는지를 나타내기 위한 포맷을 정의함. 이는 복잡한 애플리케이션 특정 알고리즘에 의해 계산될 수 있음. 예컨대, 이는 첨부파일을 설명하나 인라인 첨부파일 및 서명 블로그를 설명하지 않음. |
도 2C에 도시된 바와 같이, 전자 우편 POP3 스키마(237)는 전자 우편 프로토콜 스키마(233)로부터 도출되고, POP3 특정 데이터를 정의하는 추가적인 상관 필드(238)를 포함한다. 전자 우편 POP3 스키마(237)는 POP3 프로토콜과의 호환을 촉진하기 위해 (예컨대, 필드 전자 우편 프로토콜 스키마(233)에 따라 정의된 필드를 포함하는) 전자 우편 메시지를 확장하는 데에 이용될 수 있다. 상관 필드(238)는 표 11에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
Deleted |
Boolean |
메시지가 서버 상에서 삭제되었는지를 나타내기 위한 포맷을 정의함. |
UIDL |
String |
메시지를 동기화하는 법을 나타내기 위한 포맷을 정의함. 이 필드는 '메시지 남기기' 특징이 인에이블될 때 동기화 동안에 사용됨. UIDL는 동기화 동안에 POP3 메시지를 고유하게 식별하는데 사용됨. |
도 2C에 도시된 바와 같이, 전자 우편 NNTP 메시지 스키마(239)는 전자 우편 프로토콜 스키마(233)로부터 도출되고 NNTP 특정 데이터를 정의하는 추가적인 상관 필드(240)를 포함한다. 전자 우편 NNTP 스키마(237)는 NNTP 프로토콜과의 호환을 촉진하기 위해 (예컨대, 전자 우편 프로토콜 스키마(233)에 따라 정의된 필드를 포함하는) 전자 우편 메시지를 확장하는 데에 이용될 수 있다. 상관 필드(240)는 표 12에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
ArticleID |
Int32 |
메시지의 기사 id를 나타내기 위한 포맷을 정의함. 기사ID는 서버와 클라이언트간의 메시지를 조절하기 위해 NNTP 프로토콜에 의해 사용됨. |
IsArticleExpired |
Boolean |
메시지가 서버로부터 삭제되었는지를 나타내기 위한 포맷을 정의함. |
IsKeepBody |
Boolean |
메시지 본문이 클린업(cleanuo)시에 저장되어야 하는지를 나타내기 위한 포맷을 정의함. |
Lines |
Int64 |
메시지의 라인 수를 나타내기 위한 포맷을 정의함. |
도 2C에 도시된 바와 같이, 전자 우편 커뮤니티 뉴스 스키마(241)는 또한 전자 우편 NNTP 스키마(239)로부터 도출되고, 커뮤니티 뉴스 특정 데이터를 정의하는 추가적인 상관 필드(242)를 포함한다. 전자 우편 커뮤니티 뉴스 스키마(241)는 커뮤니티 뉴스 메시지와의 호환을 촉진하기 위해 (예컨대, 전자 우편 NNTP 스키마(239)에 따라 정의된 필드를 포함하는) NNTP 메시지를 확장하는 데에 이용될 수 있다. 상관 필드(242)는 표 13에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
CommunityStatus |
String |
게시자가 매우 원하는 게시물을 발견하였는지를 나타내기 위한 포맷을 정의함. 가능한 값은 다음과 같다: 1) Not Included: 이용 가능한 데이터 없음, 2) 게시자Approved: 게시자가 이 질문을 충분히 처리하는 게시물을 읽음, 3) OtherApproved: 게시자의 다른 카테고리는 답변이 이 질문을 충분히 처리하였음을 나타냄. |
FeedBack |
String |
사용자가 제출한 피드백의 타입을 나타내기 위한 포맷을 정의함. 가능한 값은 다음과 같다: 1) Not Included: 제출된 데이터 없음, 2) Answered: 이는 이 답변이 묻는 질문을 충분히 처리하였음을 나타냄, 3) Helpful: 이 게시물은 도움이 되었음, 4) NotHelpful: 이 게시물은 도움이 되지 않았음. |
PosterID |
String |
게시자를 고유하게 식별하는 식별자를 나타내기 위한 포맷을 정의함. 게시물이 인증되지 않은 경우 이 필드는 생략될 수 있음. |
PosterType |
String |
뉴스 그룹 게시자의 타입을 나타내기 위한 포맷을 정의함. 가능한 값은 다음과 같다: 1) Not Included: 지정된 타입이 없음, 2) MVP: 이 게시자는 MVP임. |
PostType |
String |
뉴스 그룹 게시물의 타입을 나타내기 위한 포맷을 정의함. 가능한 값음 다음과 같다: Not Included: 지정된 타입이 없음, 2) 질문: 이 게시물은 질문임, 3) Suggestion: 이 게시물은 제안임, 4) Comment: 이 게시물은 이전 게시물에 대한 코멘트임, 5) Answer: 이 게시물은 이저너 질문에 대한 응답임. |
ThreadID |
String |
메시지를 포함하는 쓰레드를 고유하게 지정하는 식별자를 나타내기 위한 포맷을 정의함. |
메시지 애플리케이션 확장 스키마(250)는 복수의 대응 메시지 애플리케이션과의 호환을 위해 메시지 아이템을 확장하는 데에 이용될 수 있는 복수의 애플리케이션 확장 스키마를 포함한다. 예컨대, 메시지 애플리케이션 프로토콜 확장 스키마(250)는 블로그 애플리케이션, 제1 전자 우편 애플리케이션, 및 제2 전자 우편 애플리케이션과의 호환을 각각 촉진시킬 수 있는 블로그 애플리케이션 스키마(251), 전자 우편 애플리케이션 스키마(253), 및 제2 전자 우편 애플리케이션 스키마(255)를 포함한다. 메시지 애플리케이션 확장 스키마(250)에 명확하게 나타낸 스키마의 앞, 사이 및 뒤에 있는 생략부호는 메시지 애플리케이션 확장 스키마(250)가 (예컨대, 음성 메시지 애플리케이션, 팩스 애플리케이션, 뉴스 그룹 애플리케이션 등과의 호환을 위해 메시지 아이템을 확장하기 위해) 추가적인 스키마를 포함할 수 있음을 나타낸다.
수직 생략부호(252, 256)는 블로그 애플리케이션 스키마(251) 및 제2 전자 우편 애플리케이션 스키마(255)가 각각 하나 이상의 상관 데이터 필드를 포함함을 나타낸다. 하나 이상의 상관 데이터 필드는 대응 메시지 애플리케이션과의 호환을 위해 메시지 아이템을 확장하는 데에 이용될 수 있다. 예컨대, 전자 우편 애플리케이션 스키마(253)는 특별한 전자 우편 애플리케이션과의 호환을 위해 메시지 아이템 확장하는 데에 이용될 수 있는 상관 필드(254)를 포함한다. 특별한 전자 우편 애플리케이션은 제2 전자 우편 애플리케이션 스키마(255)에 대응하는 제2 전자 우편 애플리케이션과는 다를 수 있다. 특히, 상관 필드(254)는 표 14에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
ForwardTo |
String |
메시지가 자동 전송되어야 하는지를 나타내기 위한 포맷을 정의함. |
HasPartialReceiveTime |
Boolean |
수신된 시간에 포함되었는지를 나타내는 포맷을 정의함. |
HighlightColor |
String |
메시지를 강조하는 데에 사용된 색상을 나타내기 위한 포맷을 정의함. 규칙 또는 필터에 매칭될 때 메시지가 색상 강조되도록 함. 가능한 값은 없음, Colorl, Color2, ... 또는 Color16. |
IMAPUID |
Int32 |
IMAP 서버 상의 메시지의 고유 식별자를 나타내기 위한 포맷을 정의함. |
IsIMAPDelayedDelete |
Boolean |
메시지가 IMAP 지연 삭제 마크되었는지를 지시하기 위한 포맷을 정의함. |
IsMarkedForDownload |
Boolean |
메시지가 다운로드 마크되었는지를 지시하기 위한 포맷을 정의함. |
IsNewsGroupMessage |
Boolean |
메시지가 뉴스 그룹 메시지인지를 나타내기 위한 포맷을 정의함. |
IsReceiptProcessed |
Boolean |
수신이 이미 처리되었는지를 나타내기 위한 포맷을 정의함. |
IsReceiptSent |
Boolean |
수신이 전송되었는지를 지시하기 위한 포맷을 정의함. |
IsSavedOffline |
Boolean |
오프라인 모드 동안에 메시지가 저장되었는지를 지시하기 위한 포맷을 정의함. |
RecHeader |
String |
메시지에서 발견된 'X-MSOESRec' 헤더를 나타내기 위한 위한 포맷을 정의함. |
PartialID |
String |
메시지 부분 ID를 나타내기 위한 포맷을 정의함. 포함된 경우, 값은 메시지/부분 메시지의 Content-Type내의 'id' 파라미터임. |
PartialNumber |
Int32 |
메시지의 부분 개수를 나타내기 위한 포맷을 정의함. 포함된 경우, 값은 메시지/부분 메시지 Content-Type내의 '개수' 파라미터임. |
PartialTotal |
Int32 |
메시지의 부분 합계를 나타내기 위한 포맷을 정의함. 포함된 경우, 값은 메시지/부분 메시지의 Content-Type내의 'total' 파라미터임. 가능한 값은 다음과 같다: 0 또는 포함되지 않음: 메시지는 '메시지/부분' Content-Type 메시지임. -1: 메시지는 전체 메시지이고, '메시지/부분' Content-Type 메시지의 모든 부분을 성공적으로 joining함으로써 발생되었음. 1 이상: 메시지는 '메시지/부분' Content-Type 메시지임. |
Refs |
String |
이 메시지가 참조하는 쓰레드의 Id를 나타내기 위한 포맷을 정의함. NNTP 및 IMAP에서 사용될 수 있음. |
UserCodePageOverride |
Int32 |
메시지를 유니코드로 변환하기 위해 코드 페이지를 나타내기 위한 포맷을 정의함. 코드 페이지 값은 메시지에 지정된 코드 페이지와 다른 코드 페이지를 갖는 메시지를 디코드하기 위해 선택하는 사용자로부터 얻어짐. |
WasDeletedOffline |
Boolean |
오프라인 모드 동안에 메시지가 삭제되었는지를 나타내기 위한 포맷을 정의함. |
WatchStatus |
String |
메시지가 대화 쓰레드에 대해 무시, 감시, 또는 둘다 아님을 나타내기 위한 포맷을 정의함. 가능한 값은 없음, 감시, 또는 무시임. |
XRef |
String |
XRef 헤더의 값을 나타내기 위한 포맷을 정의함. |
도 2D에 도시된 바와 같이, 스키마 계층구조(200)는 폴더 프로토콜 확장 스키마(260) 및 폴더 애플리케이션 확장 스키마(270)를 포함하는 복수의 폴더 확장 스키마를 포함한다. 폴더 프로토콜 확장 스키마(260)는 복수의 대응 폴더 프로토콜과의 호환을 위해 폴더 아이템을 확장하는 데에 사용될 수 있는 복수의 폴더 프로토콜 확장 스키마를 포함한다. 예컨대, 폴더 프로토콜 확장 스키마(260)는 음성 메시지 폴더 프로토콜, 전자 우편 폴더 프로토콜, 및 블로그 엔트리 폴더 프로토콜와의 호환을 각각 촉진시킬 수 있는 음성 메시지 폴더 프로토콜 스키마(261), 전자 우편 메시지 폴더 프로토콜 스키마(263), 및 블로그 메시지 폴더 프로토콜 스키마(267)를 포함한다. 폴더 프로토콜 확장 스키마(260)에 명확하게 나타낸 스키마의 앞, 사이 및 뒤에 있는 생략부호는 폴더 프로토콜 확장 스키마(260)가 (예컨대, 인스턴트 메시지 폴더 프로토콜 및 팩스 폴더 프로토콜 등과의 호환을 위한 폴더 아이템을 확장하기 위한) 추가적인 스키마를 포함할 수 있음을 나타낸다.
수직 생략부호(262, 264, 268)는 음성 메시지 폴더 프로토콜 스키마(261), 전자 우편 메시지 폴더 프로토콜 스키마(263), 및 블로그 엔트리 폴더 프로토콜 스키마(267)가 각각 하나 이상의 상관 데이터 필드를 포함할 수 있음을 나타낸다. 하나 이상의 데이터 상관 데이터 필드는 대응 폴더 프로토콜와의 호환을 위해 폴더 아이템을 확장하는 데에 이용될 수 있다. 도 2D에 도시된 바와 같이, 전자 우편 IMAP 폴더 스키마(265)는 또한 전자 우편 메시지 폴더 프로토콜 스키마(263)로부터 도출되고, IMAP 특정 데이터를 정의하는 추가적인 상관 필드(266)를 포함한다. 전자 우편 IMAP 폴더 스키마(265)는 IMAP 폴더와의 호환을 촉진하기 위해 (예컨대, 전자 우편 메시지 폴더 프로토콜 스키마(263)에 따라 정의된 필드를 포함하는) 전자 우편 메시지 폴더를 확장하는 데에 이용될 수 있다. 상관 필드(266)는 표 15에 나타낸 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
CanSelect |
Boolean |
UI가 이 폴더를 선택되도록 하는지를 나타내기 위한 포맷을 정의함. |
CharSet |
String |
유니코드 폴더명을 전송하기 위해 UTF-7의 수정된 버전을 이용하는 법을 나타내는 포맷을 정의함. 폴더명이 서버로부터 수신되고 UTF-7에서 RFC 2060 섹션 5.1.3의 인코딩 방법을 따르지 않은 경우, 로컬 사용자의 문자세트는 이 필드에 기록됨. 서버가 UTF-7로 인코딩하지 않은 경우, 윈도우 코드 페이지를 이용하는 레거시 클라이언트일 가능성이 있음. 이 값이 설정되면, 서버로부터 수신된 폴더명은 BASE-64 인코딩으로 변환되어 MaiI.IMAPFolder.DisplayName 내의 유니코드에 저장됨. |
HasChildren |
Boolean |
폴더가 자식들(children)을 갖기 때문에 플러스 부호가 UI에 표시되어야 하는지를 나타내기 위한 포맷을 정의함. |
HierarchyDelimeter |
String |
IMAP 서버상의 폴더 경로를 나타내기 위한 포맷을 정의. 이 문자는 유니코드로 저장될 수 있으나, US 코드 페이지를 이용하여 ANSI로 변환될 때, 높은 비트 세트를 갖기 않게 됨. |
IsSubscribed |
Boolean |
폴더가 가입되었는지를 나타내기 위한 포맷을 정의함. 이는 IMAP, NNTP, 또는 전송이 가입될 수 없는 폴더에 대해 행해질 수 있음. |
MarkedForDeletion |
Boolean |
폴더가 IMAP 삭제 표시되고 모든 자식 폴더가 삭제될 때 서버상에서 삭제되는지를 나타내기 위한 포맷을 정의함. |
UIDValidity |
Int32 |
IMAP 폴더의 UIDVALIDITY 값을 나타내기 위한 포맷을 정의함. 'UIDVALIDITY' 응답으로 IMAP 서버로부터 반환될 수 있음. |
폴더 애플리케이션 확장 스키마(270)는 복수의 대응 폴더 애플리케이션과의 호환을 위해 폴더 아이템을 확장하는 데에 사용될 수 있는 복수의 애플리케이션 확장 스키마를 포함한다. 예컨대, 폴더 애플리케이션 확장 스키마(270)는 인스턴트 메시지 폴더 애플리케이션, 제1 전자 우편 폴더 애플리케이션, 및 제2 전자 우편 폴더 애플리케이션과의 호환을 각각 촉진시키는 인스턴트 메시지 폴더 애플리케이션 스키마(271), 전자 우편 메시지 폴더 애플리케이션 스키마(273) 및 제 2 전자 우편 폴더 애플리케이션 스키마(275)를 포함한다. 폴더 애플리케이션 확장 스키마(270)에 명확하게 나타낸 스키마의 앞, 사이, 위에 있는 생략부호는 폴더 애플리케이션 확장 스키마(270)가 (예컨대, 블로그 엔트리 폴더 애플리케이션, 팩스 폴더 애플리케이션 등과의 호환을 위해 폴더 아이템을 확장시키기 위한) 추가적인 스키마를 포함할 수 있음을 나타낸다.
수직 생략부호(272, 276)는 인스턴트 메시지 애플리케이션 폴더 스키마(271) 및 제2 전자 우편 메시지 애플리케이션 폴더 스키마(275)가 하나 이상의 상관 데이터 필드를 포함할 수 있음을 나타낸다. 하나 이상의 상관 데이터 필드는 대응 폴더 애플리케이션과의 호환을 위해 폴더 아이템을 확장하는 데에 이용될 수 있다. 예컨대, 전자 우편 메시지 애플리케이션 폴더 스키마(273)는 특별한 전자 우편 폴더 애플리케이션과의 호환을 위해 폴더 아이템을 확장하는 데에 이용될 수 있는 상관 필드(274)를 포함한다. 특별한 전자 우편 폴더 애플리케이션은 제2 전자 우편 메시지 폴더 애플리케이션 스키마(275)에 대응하는 제2 전자 우편 폴더 애플리케이션과 다를 수 있다. 특히, 상관 필드(274)는 표 16에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
CanDelete |
Boolean |
폴더가 삭제될 수 있는지를 나타내기 위한 포맷을 정의함. 폴더가 전자 우편 애플리케이션 또는 서버에 의해 필요한지를 나타낼 수 있음. |
CanRename |
Boolean |
폴더의 이름 바꾸기가 가능한지를 나타내기 위한 폴더를 정의함. 일부 서버는 폴더 이름 바꾸기를 억제함. 예컨대, IMAP는 "드래프트" 및 "전송된 아이템"과 같은 특수 폴더의 이름 바꾸기를 억제할 수 있음. |
FolderCreatedOffline |
Boolean |
폴더가 오프라인에서 생성되었고, 온라인으로 다시 천이될 때 서버 상에서 생성되어야 하는지를 나타내기 위한 포맷을 정의함. |
FolderExpanded |
Boolean |
폴더가 확장 상태인지를 나타내기 위한 포맷을 정의함. |
IsFolderHidden |
Boolean |
UI 내의 폴더 트리로부터 폴더를 숨겨야 하는지를 나타내기 위한 포맷을 정의함. 폴더를 숨기기 위해 사용자에 의해 사용될 수 있음.. |
StatusMsgDelta |
Int32 |
IMAP 상태 응답을 통해 부가된 메시지의 개수를 나타내기 위한 포맷을 정의함. |
StatusUnReadDelta |
Int32 |
IMAP 상태 응답을 통해 부가된 비판독 메시지의 개수를 나타내기 위한 포맷을 정의함. |
URLComponent |
String |
서버 상의 폴더로 맵핑하기 위해 전송에 의해 사용될 수 있는 URl/URL 나타내기 위한 포맷을 정의함. |
도 2D에 도시된 바와 같이, 전자 우편 뉴스 메시지 폴더 애플리케이션 스키마(277)는 전자 우편 메시지 폴더 애플리케이션 스키마(273)로부터 도출되고, 뉴스 메시지 특정 데이터를 정의하는 추가적인 상관 필드(278)를 포함한다. 전자 우편 뉴스 메시지 애플리케이션 폴더 스키마(277)는 뉴스 메시지 폴더 애플리케이션과의 호환을 촉진하기 위해 (예컨대, 전자 우편 메시지 폴더 애플리케이션 스키마(273)에 따라 정의된 필드를 포함하는) 전자 우편 메시지 폴더를 확장하는 데에 이용될 수 있다. 상관 필드(278)는 표 17에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
ClientRange |
ArticleRange |
클라이언트상의 기사의 범위를 나타내기 위한 포맷을 정의함. |
CommunitiesLastRefresh |
DateTime |
커뮤니티 동적 속성이 리프레쉬된 최종 날짜 및 시간을 나타내기 위한 포맷을 정의함. |
CommunityRange |
ArticleRange |
커뮤니티 헤더 속성과 동기된 기사 ID 범위의 컬렉션을 나타내기 위한 포맷을 정의함. |
HighestArticleChecked ForWatch |
Int32 |
감시 정보를 위해 체크된 가장 높은 번호의 기사를 나타내기 위한 포맷을 정의함. |
IsNewNewsGroup |
Boolean |
폴더가 새로운 뉴스 그룹인지를 나타내기 위한 포맷을 정의함. |
PostAccess |
String |
뉴스 그룹 게시물을 허용하는 법을 나타내기 위한 포맷을 정의함. 일부 뉴스 그룹은 게시물을 허용하는지 또는 게시물을 허용하는 방법을 제한할 수 있음. 가능한 값은 다음과 같다: 1) Not Incuded: 액세스 제한이 부가되지 않음. 2) NoPosting: 이 서버에 대해 게시물의 형성이 허용되지 않음. 3) Moderated: 이 서버에 대한 게시물이 적절함. 4) Blocked: 이 서버에 대한 게시물이 차단됨. |
ReadRange |
ArticleRange |
읽은 기사 lD 범위의 컬렉션을 나타내기 위한 포맷을 정의함. |
SynchronizedRange |
ArticleRange |
이 폴더에 대해 동기된 기사 lD 범위 컬렉션을 나타내기 위한 포맷을 정의함.. |
Tota1Article |
Int32 |
뉴스 그룹 서버 상에 기사의 카운트를 나타내기 위한 포맷을 정의함.. |
TotalNotDownloaded |
Int32 |
아직 다운로드되지 않은 뉴스 그룹 메시지의 개수를 나타내기 위한 포맷을 정의함. |
TotalWatched |
Int32 |
감시 메시지의 개수를 나타내기 위한 포맷을 정의함. |
UnreadWatched |
Int32 |
읽지 않은 감시 메시지의 개수를 나타내기 위한 포맷을 정의함. |
도 2D에 도시된 바와 같이, 기사 범위 스키마(281)는 기사 범위를 나타내기 위한 포맷을 정의하는 상관 필드(282)를 포함한다. 상관 필드(282)는 표 18에 기술된 데이터 포맷을 정의할 수 있다.
필드명 |
필드 데이터 타입 |
필드 설명 |
High |
Int32 |
동기된 범위 내의 High ArticlelD 값을 나타내기 위한 포맷을 정의함. |
Low |
Int32 |
동기된 범위 내의 Low ArticlelD 값을 나타내기 위한 포맷을 정의함. |
예컨대, 스키마 계층구조(150) 또는 스키마 계층구조(200)와 같은 스키마 계층구조에 포함된 스키마는 데이터베이스(114)에 저장된 데이터베이스 아이템을 생성하는 데에 이용될 수 있다. 예컨대, 기본 아이템 스키마(151), 메시지 스키마(152) 및 메시지 프로토콜 확장 스키마(161)로부터의 잠재적으로 하나 이상의 메시지 프로토콜 확장 스키마 및/또는 메시지 애플리케이션 확장 스키마(166)로부터의 하나 이상의 메시지 애플리케이션 스키마는 전자 메시지를 생성하는 데에 이용될 수 있다. 도 3은 본 발명의 원리에 따라 포맷된 예시적인 전자 메시지(300)를 나타낸다. 도 8은 본 발명의 원리에 따라 전자 메시지를 생성하는 방법(800)의 예시적인 플로우챠트를 나타낸다. 방법(800)은 네트워크 구조(100), 스키마 계층구조(150) 및 전자 메시지(300)에 대해 설명된다. 네트워크 구조(100)(즉, 메시지 아이템(107, 108, 112, 및 116))에 나타낸 임의의 메시지는 포맷이 전자 메시지(300)와 유사할 수 있다.
방법(800)은 전자 메시지를 나타내는 메시지 아이템을 생성하는 동작을 포함한다(동작 801). 동작(801)은 컴퓨터 시스템이 전자 메시지를 나타내는 메시지 아이템을 생성하는 동작을 포함할 수 있다. 예컨대, 컴퓨터 시스템(102) 또는 컴퓨터 시스템(109)은 전자 메시지(예컨대, 전자 메시지 아이템(108 또는 112))을 나타내는 메시지 아이템을 생성할 수 있다. 메시지 아이템은 사용자-인터페이스의 "새로운 메시지" 옵션의 선택과 같은 사용자 입력에 응답하여 선택된다. 사용자 입력은 키보드 또는 마우스와 같은 로컬 입력 장치로부터 국부적으로 수신될 수 있고, 또는 원격 위치로부터, 예컨대, 일부 다른 접속 가능 컴퓨터 시스템으로부터 수신될 수 있다.
메시지 아이템의 생성은 기본 아이템 스키마(151) 및 메시지 스키마(152)에 따라 정의된 하나 이상의 필드를 포함하는 데이터 구조의 생성을 포함할 수 있다. 기본 아이템 스키마(151) 및 메시지 스키마(152)에 따라 정의된 필드는 복수의 다른 타입의 전자 메시지에 공통적인 일반 속성을 나타낼 수 있다. 일반 속성(301)은 복수의 다른 타입의 전자 메시지에 공통적일 수 있는 메시지 속성 필드의 예이다. 예컨대, GUID(globally unique indentifier)와 같은 식별자가 ID 필드(302)에 할당될 수 있다. 할당된 식별자는 전자 메시지(300)를 나타내는 메시지 아이템과 데이터베이스(114) 내의 다른 아이템을 구별할 수 있다.
방법(800)은 주 타입을 생성된 메시지 아이템에 할당하는 동작을 포함한다(동작 802). 동작(802)은 컴퓨터 시스템이 주 타입을 생성된 메시지 아이템에 할당하는 동작을 포함할 수 있다. 주 메시지 타입은, 예컨대 전자 우편 메시지, 팩스 메시지, 뉴스 그룹 포스팅 등과 같은 전자 메시지(300)의 일반 행동을 나타낼 수 있다. 주 메시지 타입을 전자 메시지(300)에 할당하는 동작은, 예컨대 전자 우편 메시지, 인스턴트 메시지, 팩스 메시지, 뉴스 그룹 포스팅, 또는 블로그 엔트리를 나타내는 주 메시지 타입 값을 주 타입 필드(303)에 할당하는 동작을 포함할 수 있다. 따라서, 주 타입 필드(303)는 ID 필드(302)내의 식별자에 의해 식별된 전자 메시지의 주 메시지 타입을 나타낼 수 있다.
전자 메시지(300)의 다른 속성들이 또한 할당될 수 있다. 참가자 필드(304)에는 전자 메시지(300)(ID 필드(302) 내의 식별자에 의해 식별된 전자 메시지)와 연관된 하나 이상의 참가자로의 링크를 나타내는 하나 이상의 메시지 참가자 관계가 할당될 수 있다. 내용 필드(305)는 메시지(300)에 대응하는 메시지 내용의 하나 이상의 부분으로의 링크를 나타내는 하나 이상의 메시지 내용 관계가 할당될 수 있다. 보내기 메시지 필드(306)는 전자 메시지(300)가 전달을 위해 전송된 후 이동해야 할 하나 이상의 메시지 폴더로의 링크를 나타내는 하나 이상의 폴더 관계가 할당될 수 있다. 다운로드 상태 필드(307)에는 전자 메시지(300)에 대응하는 다운로드 상태(예컨대, 부분적 등)가 할당될 수 있다.
메시지 상태 필드(308)에는 메시지(300)의 상태를 나타내는 하나 이상의 값이 할당될 수 있다. 예컨대, 메시지 상태 필드(308)에는 메시지(300)가 판독되었는지를 나타내는 IsRead 지시, 메시지(300)의 전송 상태를 나타내는 SendStatus 지시, 전자 메시지(300)에 대해 행해진 최종 동작을 나타내는 LastActionTaken 지시, 전자 메시지(200)에 대해 최종 동작이 행해진 시간을 나타내는 LastActionTime, 및 전자 메시지 (300)에 대해 취해진 최종 동작의 타입을 나타내는 LastActionType 필드가 할당될 수 있다. 일반 속성(301)의 필드는 표 2에 기술된 데이터 포맷에 대응할 수 있다.
방법(800)은 하나 이상의 메시지 확장자에 따라 메시지 아이템을 사용자 지정화(customizing)하는 기능적 결과 지향 단계를 포함한다(단계 805). 단계(805)는 하나 이상의 메시지 확장자에 따른 메시지 아이템의 사용자 지정화를 형성하는 대응 동작을 포함할 수 있다. 그러나, 도 8의 예에서, 단계 805는 하나 이상의 프로토콜 확장자를 상기 생성된 메시지 아이템에 할당하는 대응 동작을 포함한다(동작 803).
동작(803)은 하나 이상의 프로토콜 확장자를 생성된 메시지 아이템에 할당하는 컴퓨터 시스템을 포함할 수 있다. 프로토콜 확장자의 할당은 메시지 프로토콜 확장 스키마에 따라 정의된 필드의 메시지 아이템으로의 추가(또는 필드 상의 스냅핑)를 포함할 수 있다. 메시지 프로토콜 확장자는 포맷 프로토콜 특정 속성을 나타내기 위한 포맷을 정의하는 전자 우편 프로토콜 확장(예컨대, POP3 확장자), 인스턴트 메시징 프로토콜 확장자, 팩스 프로토콜 확장자, 뉴스 그룹 포스팅 프로토콜 확장(예컨대, NNTP 또는 커뮤니티 뉴스 확장자), 블로그 엔트리 프로토콜 확장자 등을 포함할 수 있다.
일반적으로, 예컨대 프로토콜 특정 속성(310)과 같은 프로토콜 특정 속성은 하나 이상의 메시지 프로토콜에 특정된 속성을 나타낸다. 필드는 전자 메시지 (300)의 호환 요건에 기초하여 프로토콜 특정 속성(310)에 추가 또는 프로토콜 특정 속성(310)으로부터 제거될 수 있다. 예를 들면, (예컨대, 프로토콜 확장 스키마(163)에 따라 정의된) 프로토콜 특정 필드(311) 및 (예컨대, 프로토콜 확장 스키마(162)에 따라 정의된) 프로토콜 특정 필드(312)는 추가된 대응 메시지 프로토콜과의 호환을 촉진하기 위해 추가될 수 있다. 프로토콜 특정 속성(310) 내의 수직 생략부호는 다른 프로토콜 특정 필드는 또한 프로토콜 특정 속성(310)에 포함될 수 있음을 나타낸다.
도 8의 예에서, 단계 805는 하나 이상의 애플리케이션 확장자를 상기 생성된 메시지 아이템에 할당하는 대응 동작을 포함한다(동작 804). 동작(804)은 컴퓨터 시스템이 하나 이상의 애플리케이션 확장자를 상기 생성된 메시지 아이템에 할당하는 동작을 포함할 수 있다. 애플리케이션 확장자의 할당은 메시지 애플리케이션 확장 스키마에 따라 정의된 필드의 메시지 아이템에의 추가(또는 그 필드상의 스냅핑)를 포함할 수 있다. 메시지 애플리케이션 확장자는 애플리케이션 특정 속성을 나타내기 위한 포맷을 정의하는 (예컨대, Microsoft®Outlook®Expres, Microsoft®Outlook®, Eudora, Novell GroupWise® 등과의 호환을 위한) 전자 우편 애플리케이션 확장자, 인스턴트 메시징 애플리케이션 확장자, 팩스 애플리케이션 확장자, 뉴스 그룹 포스팅 애플리케이션 확장자, 블로그 엔트리 애플리케이션 확장자 등을 포함할 수 있다.
일반적으로, 예컨대 애플리케이션 특정 속성과 같은 애플리케이션 특정 속성(320)은 하나 이상의 메시지 애플리케이션에 특정된 속성을 나타낸다. 필드는 전자 메시지(300)의 호환 요건에 기초하여 애플리케이션 특정 속성(320)에 추가 또는 애플리케이션 특정 속성(320)으로부터 제거될 수 있다. 예를 들면, (예컨대, 프로토콜 확장 스키마(167)에 따라 정의된) 애플리케이션 특정 필드(321) 및 (예컨대, 프로토콜 확장 스키마(168)에 따라 정의된) 애플리케이션 특정 필드(322)는 대응 메시지 애플리케이션과의 호환을 촉진하기 위해 추가될 수 있다. 애플리케이션 특정 속성(320) 내의 수직 생략부호는 다른 애플리케이션 특정 필드는 또한 프로토콜 특정 속성(320)에 포함될 수 있음을 나타낸다.
다른 데이터베이스 아이템은 또한 스키마 계층구조(150) 또는 스키마 계층구조(200) 내의 스키마에 따라 생성될 수 있다. 도 4는 본 발명의 원리에 따라 포맷된 내용 부분(400)을 나타낸다. 내용 부분(400)은 내용 스키마(예컨대, 내용 스키마(156))에 따라 포맷된 필드를 포함할 수 있다. 메시지 링크 필드(401)에는 내용 부분(400)으로부터 전자 메시지로의 링크를 나타내는 메시지 관계가 할당될 수 있다. 내용 타입 필드(402)는 대응 내용 부분(400)의 내용 타입을 나타낼 수 있다. 순서 필드(403)는 내용 부분(400)에 대응하는 순서를 나타낼 수 있다. 내용 필드(408)는 내용 부분(400)에 대응하는 메시지 데이터(예컨대, 전자 우편 메시지의 텍스트)를 나타낼 수 있다.
내용 부분(400)이 첨부 파일이면, 내용 부분(400)은 선택적으로 첨부 파일 타입 필드(406) 및 MIME URL 필드(407)를 포함할 수 있다. 첨부 파일 타입 필드(405)는 내용 부분(400)의 첨부 파일 타입을 나타낸다. MIME URL 필드(407)는 내용 부분(400)에 대응하는 MIME 경로로의 링크를 나타낸다.
도 5는 본 발명의 원리에 따라 포맷된 예시적인 메시지 첨부 파일(500)을 나타낸다. 메시지 첨부 파일(500)은 첨부 파일 스키마(예컨대, 첨부 파일 스키마(157))에 따라 정의된 필드를 포함할 수 있다. 메시지 링크 필드(501)에는 메시지 첨부 파일(500)로부터 전자 메시지로의 링크를 나타내는 메시지 관계가 할당될 수 있다. 타입 필드(502)는 링크 필드(501) 내의 링크에 의해 전자 메시지의 메시지 타입을 나타낸다. IsPinned 필드(503)는 링크 필드(501) 내의 링크에 의해 링크된 전자 메시지에 대해 메시지 첨부 파일(500)의 삭제 상태를 나타낸다. IsTrusted 필드(504)는 메시지 첨부 파일(500)에 관련된 신뢰 정보를 나타낸다.
첨부 파일 상태 필드(506)는 메시지 첨부 파일(500)의 타입 및 행동을 나타낸다. 첨부 파일 소스 필드(507)에는 메시지 첨부 파일(500)이 액세스된 데이터베이스 아이템으로의 링크를 나타내는 관계가 할당될 수 있다. SaveFrom 필드(508)에는 메시지 첨부 파일(500)로의 링크를 나타내는 관계가 할당될 수 있다. 첨부 파일 데이터 필드(509)는 메시지 첨부 파일(500)에 대응하는 첨부 파일 데이터(예컨대, MP3의 내용)을 나타낼 수 있다.
도 6은 본 발명의 원리에 따라 포맷된 예시적인 커뮤니티 뉴스 폴더(600)를 나타낸다. 커뮤니티 뉴스 폴더(600)는 폴더 스키마(예컨대, 폴더 스키마(154)) 및 잠재적으로 하나 이상의 폴더 확장 스키마(예컨대, 전자 우편 뉴스 메시지 애플리케이션 폴더 스키마(277))에 따라 정의된 필드를 포함할 수 있다. 커뮤니티 범위 필드(601)는 커뮤니티 헤더 속성과 동기된 뉴스 그룹 커뮤니티로부터의 기사 ID의 컬렉션(collection)을 나타낸다. 커뮤니티 최종 리프레쉬 필드(602)는 커뮤니티 범위 필드(601)에 나타낸 동기화된 기사 ID의 컬렉션을 포함하는 뉴스 그룹 커뮤니티의 커뮤니티 동적 속성이 리프레쉬된 최종 시간을 나타낸다. 낮은 기사 ID 필드(603)는 커뮤니티 범위 필드(60I)에 나타낸 동기화된 기사 ID의 컬렉션에 포함된 낮은 기사 ID를 나타낸다. 높은 기사 ID 필드(604)는 커뮤니티 범위 필드(601)에 나타낸 동기화된 기사 ID의 컬렉션에 포함된 높은 기사 ID를 나타낸다.
일부 실시예들에서, 하나의 메시지 확장 스키마에 따라 정의된 필드 내의 값이 검색되어 다른 메시지 확장 스키마에 따라 정의된 필드를 파퓰레이팅하는 데에 이용된다. 따라서, 전자 메시지는 다른 확장 스키마에 대응하는 프로토콜 또는 애플리케이션과의 호환을 위해 효율적으로 변환될 수 있다. 도 9는 본 발명의 원리에 따라 메시지 확장자와의 호환을 위해 전자 메시지를 변환하는 방법(900)의 예시적인 플로우챠트를 나타낸다. 방법(900)은 네트워크 구조(100) 및 스키마 계층구조(150)에 대해 설명한다.
방법(900)은 전자 메시지를 나타내는 메시지 아이템을 액세스하는 동작(동작(901))을 포함한다. 동작(901)은 전자 메시지를 나타내는 메시지 아이템을 액세스하는 컴퓨터 시스템을 포함할 수 있다. 예컨대, 컴퓨터 시스템(102)은 메시지 아이템(107)을 액세스할 수 있다. 유사하게, 컴퓨터 시스템(109)은 메시지(116) 또는 메시지 아이템(108)을 액세스할 수 있다.
방법(900)은 새로운 메시지 확장과의 호환을 위해 전자 메시지 아이템을 변환하기 위한 현재 할당된 확장자 특정 필드의 값을 이용하는 기능적 결과 지향 단계를 포함한다(단계(905)). 단계(905)는 새로운 메시지 확장자와의 호환을 위해 전자 메시지 아이템을 변환하기 위해 현재 할당된 확장자 특정 필드의 값을 이용하는 대응 동작을 포함할 수 있다. 그러나, 도 9의 예에서, 단계(905)는 새로운 메시지 확장자를 메시지 아이템에 할당하는 대응 동작을 포함한다(동작 902).
동작(902)은 새로운 메시지 확장자를 메시지 아이템에 할당하는 컴퓨터 시스템을 포함할 수 있다. 예컨대, 컴퓨터 시스템(102)은 새로운 메시지 확장자를 메시지 아이템(107)에 할당할 수 있다. 유사하게, 컴퓨터 시스템(109)은 새로운 메시지 확장자를 메시지 아이템(108) 또는 메시지 아이템(116)에 할당할 수 있다. 새롭게 할당된 메시지 확장자는 메시지 프로토콜 확장 스키마 또는 메시지 애플리케이션 확장 스키마에 따라 정의된 하나 이상의 데이터 필드를 포함할 수 있다. 예컨대, 컴퓨터 시스템(109)은 메시지 애플리케이션(103)(인스턴트 메시징 애플리케이션)과의 호환을 촉진하기 위해 새로운 메시지 확장자(인스턴트 메시지 애플리케이션 확장자)를 메시지 아이템(107)(현재 할당된 전자 우편 애플리케이션 확장자)에 할당할 수 있다. 전자 우편 메시지 및 인스턴트 메시지는 하나 이상의 유사한 필드를 갖는다. 그러나, 하나 이상의 유사한 필드는, 예컨대 음성 메시지 및 팩스 메시지와 같은 다른 다양한 타입의 전자 메시지의 필드와 유사할 수 있다. 따라서, 하나 이상의 유사한 필드는 일반 메시지 스키마(예컨대, 메시지 스키마(152))에 포함될 수는 없다.
컴퓨터 시스템은 현재 할당된 메시지 확장자 및 새로운 메시지 확장에 따라 메시지 아이템을 전송할 수 있다. 따라서, 메시지 아이템의 내용을 복제하지 않고도 하나의 메시지 아이템은 다수의 애플리케이션에 전송될 수 있다. 하나의 메시지 아이템의 전송은 일치하는 데이터를 수신하는 다른 애플리케이션, 예컨대 전자 우편 애플리케이션 및 팩스 애플리케이션의 가능성을 증가시킨다.
도 9에 나타낸 예에서, 단계(905)는 하나 이상의 현재 할당된 특정 속성으로부터 적어도 하나의 값을 검색하는 대응 동작을 포함한다(동작(903)). 동작(903)은 하나 이상의 현재 할당된 특정 속성으로부터 적어도 하나의 값을 검색하는 컴퓨터 시스템을 포함할 수 있다. 예컨대, 컴퓨터 시스템(102)은 메시지 아이템(107 또는 108)의 하나 이상의 현재 할당된 특정 속성으로부터 적어도 하나의 값을 검색할 수 있다. 유사하게, 컴퓨터 시스템(109)은 메시지 아이템(112 또는 116)의 하나 이상의 현재 할당된 특정 속성을 적어도 하나의 값을 검색할 수 있다.
메시지 애플리케이션(111)은 다른 메시징 애플리케이션과의 호환을 위해 메시지를 변환하도록 구성된 애플리케이션일 수 있다. 메시징 애플리케이션(111)은 예컨대 현재 할당된 팩스 애플리케이션 확장자인 메시지 아이템(116)을 검색할 수 있다. 메시징 애플리케이션(111)은 현재 할당된 속성(즉, 팩스 속성)이 (예컨대, 전자 우편 애플리케이션 확장자에 대응하는) 새로운 속성과 유사한지를 결정하기 위해 팩스 애플리케이션 확장자의 현재 할당된 속성을 분석할 수 있다. 예컨대, 팩스 애플리케이션 및 전자 우편 애플리케이션은 메시지가 유사한 방식으로 오프라인 저장될 수 있음을 나타낸다. 따라서, 팩스 애플리케이션에 대응하는 저장된 오프라인 값은 또한 전자 우편 애플리케이션에 해당할 수도 있다. 따라서, 이 저장된 오프라인 값은 팩스 애플리케이션 확장자로부터 검색될 수 있다.
도 9의 예에서, 단계(905)은 선택적으로 검색된 적어도 하나의 값을 적어도 하나의 새로운 특정 속성에 할당하는 대응 동작을 포함한다(동작 904). 동작(904)은 컴퓨터 시스템이 검색된 적어도 하나의 값을 적어도 하나의 새로운 특정 속성에 할당하는 동작을 포함할 수 있다. 예컨대, 컴퓨터 시스템(102)은 검색된 적어도 하나의 값을 메시지 아이템(107 또는 108)의 적어도 하나의 새로운 특정 속성에 할당할 수 있다. 유사하게, 컴퓨터 시스템(109)은 검색된 적어도 하나의 값을 메시지 아이템(112 또는 116)의 적어도 하나의 새로운 특정 속성에 할당할 수 있다.
예컨대, 메시지 애플리케이션(111)은 팩스 애플리케이션 속성의 검색된 값을 유사한 전자 우편 애플리케이션 속성의 값으로서 할당할 수 있다. 따라서, 할당된 값은 전자 우편 애플리케이션의 호환을 촉진할 수 있다. 메시지 애플리케이션(111)은 데이터베이스(114)에 변환된 메시지를 (예컨대, 메시지 아이템(112)으로서)) 저장할 수 있다. 대안적으로, 메시지 애플리케이션은 변환된 메시지를 (예컨대, 메시지 아이템(107)으로서) 컴퓨터 시스템(102)에 전송할 수 있다. 예컨대, 메시지 애플리케이션(103)과 같은 대응 전자 우편 애플리케이션은 액세스 메시지 아이템(107)을 호환 가능하게 액세스할 수 있다.
일부 실시예들에서, 클라이언트 컴퓨터 시스템은 변환을 위해 전자 메시지를 서버 컴퓨터 시스템에 전송할 수 있다. 예컨대, 메시지 아이템(108)은 메시지 애플리케이션(108)에 구성될 수 있다. 다음에, 메시지 애플리케이션(104)은 메시지 아이템(108)을 요청할 수 있다. 따라서, 컴퓨터 시스템(102)은 변환을 위해 메시지 아이템(108)을 컴퓨터 시스템(109)에 제출할 수 있다. 컴퓨터 시스템(109)은 (예컨대, 대응 애플리케이션 확장자의 필드를 파퓰레이팅함으로써) 메시지 애플리케이션(l04)과의 호환을 위해 메시지를 변환할 수 있다. 변환된 메시지, 예컨대 메시지 아이템(107)은 컴퓨터 시스템(102)으로 반환될 수 있다. 메시지 애플리케이션(104)은 액세스 메시지 아이템(107)을 액세스할 수 있다.
메시지 아이템의 변환은 데이터베이스(114)의 다른 사일로 내의 정보를 참조하는 동작을 포함할 수 있다. 예컨대, 팩스 애플리케이션 확장자와의 호환을 위해 전자 우편 애플리케이션 확장자에 현재 할당된 메시지를 변환할 때, 메시지 애플리케이션은 콘택 사일로(182) 내의 정보를 참조할 수 있다. 메시지 애플리케이션은 예컨대 메시지 내에 포함된 전자 우편 주소를 갖는 참가자에 대응하는 전화 번호를 찾을 수 있다.
도 7 및 이하의 설명은 본 발명이 구현되는 적합한 컴퓨팅 환경의 간단한 일반 설명을 제공하도록 의도된다. 필요하지 않더라도, 본 발명은 프로그램 모듈과 같은 컴퓨터 실행가능 명령의 일반 관점으로 설명된다. 일반적으로, 프로그램 모듈은 특별한 작업을 수행하거나 특별한 요약 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 구성 요소, 데이터 구조 등을 포함한다. 컴퓨터 실행가능 명령, 관련 데이터 구조 및 프로그램 모듈은 여기서 설명된 방법의 동작들을 실행하기 위한 프로그램 코드 수단의 예를 나타낸다.
도 7을 참조하면, 본 발명을 구현하는 예시적인 시스템은 처리 유닛(721), 시스템 메모리(722), 및 처리 유닛(721)에 시스템 메모리(722)를 포함하는 각종 시스템 구성 요소를 연결하는 시스템 버스(723)를 포함하는 컴퓨터 시스템(720)의 형태로 범용 컴퓨팅 장치를 포함한다. 처리 유닛(721)은 본 발명의 특징을 포함하여 컴퓨터 시스템(720)의 특징을 구현하도록 설계된 컴퓨터 실행가능 명령을 실행할 수 있다. 시스템 버스(723)는 다양한 버스 구조를 이용하는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 로컬 버스를 포함하는 여러 타입의 버스 구조를 가질 수 있다. 시스템 메모리는 판독 전용 메모리("ROM")(724) 및 랜덤 액세스 메모리("RAM")(725)를 포함한다. 예컨대, 시동(start-up) 중에 컴퓨터 시스템(720) 내의 각 요소들간의 정보를 전송하는 데에 도움이 되는 기본 루틴을 포함하는 기본 입/출력 시스템("BIOS")(726)은 ROM(724)에 저장될 수 있다.
컴퓨터 시스템(720)는 또한 자기 하드 디스크(739)에 대한 판독 및 기록을 위한 자기 하드 디스크 드라이브(727), 소거 가능 자기 디스크(729)에 대한 판독 또는 기록을 위한 자기 디스크 드라이브(728), 및 예컨대 CD-ROM 또는 다른 광학 매체와 같은 소거 가능 광학 디스크(731)에 대한 판독 또는 기록을 위한 광학 디스크 드라이브(730)를 포함할 수 있다. 자기 하드 디스크 드라이브(727), 자기 디스크 드라이브(728) 및 광학 디스크 드라이브(730)는 하드 디스크 드라이브 인터페이스(732), 자기 디스크 드라이브-인터페이스(733) 및 광학 드라이브 인터페이스(734)에 의해 각각 시스템 버스(723)에 연결된다. 드라이브 및 관련 컴퓨터 판독가능 매체는 컴퓨터 시스템(720)에 컴퓨터 실행가능 명령, 데이터 구조, 프로그램 모듈, 및 다른 데이터의 비휘발성 저장소(storage)를 제공한다. 본원에서 설명한 예시적인 환경은 자기 하드 디스크(739), 소거 가능 자기 디스크(729) 및 소거 가능 광학 디스크(731)를 이용하나, 자기 카세트, 플래시 메모리 카드, DVD(digital versatile Disk), 베르누이(Bernoulli) 카트리지, RAM, ROM 등을 포함하여 데이터를 저장하기 위한 다른 타입의 컴퓨터 판독 가능 매체를 사용할 수 있다.
운영 체제(735), 하나 이상의 응용 프로그램(736), 다른 프로그램 모듈(737), 및 프로그램 데이터(738)를 포함하여, 하나 이상의 프로그램 모듈을 구비하는 프로그램 코드 수단은 하드 디스크(739), 자기 디스크(729, 광학 디스크(731), ROM(724) 또는 RAM(725) 상에 저장될 수 있다. 사용자는 키보드(740), 포인팅 장치(742), 또는 예컨대 마이크, 조이스틱, 게임 패드, 스캐너 등과 같은 다른 입력 장치(도시되지 않음)를 통해 컴퓨터 시스템(720)에 명령 및 정보를 입력할 수 있다. 이들 및 다른 입력 장치는 시스템 버스(723)에 연결된 입/출력 인터페이스(746)를 통해 처리 유닛(721)에 연결될 수 있다. 입/출력 인터페이스(746)은 예컨대 직렬 포트 인터페이스, PS/2 인터페이스, 병렬 포트 인터페이스, USB(Universal Serial Bus) 인터페이스, or IEEE(Institute of Electrical and Electronics Engineers) 1394 인터페이스(즉, FireWire 인터페이스)와 같은 다양한 다른 인터페이스를 논리적으로 나타낼 수 있고, 또는 심지어 다른 인터페이스들의 조합을 논리적으로 나타낼 수 있다.
모니터(747) 또는 다른 디스플레이 장치는 또한 비디오 인터페이스(748)를 통해 시스템 버스(723)에 연결될 수 있다. 스피커(769) 또는 다른 오디오 출력 장치는 또한 오디오 인터페이스(749)를 통해 시스템 버스(723)에 연결될 수 있다. 예컨대, 프린터와 같은 다른 주변 출력 장치(도시되지 않음)는 또한 컴퓨터 시스템(720)에 연결될 수 있다.
컴퓨터 시스템(720)은 예컨대 사무실형 또는 기업형 컴퓨터, 홈 네트워크, 인트라넷 및/또는 인터넷과 같은 네트워크에 접속 가능하다. 컴퓨터 시스템(720)은 이와 같은 네트워크을 통해, 예컨대 원격 컴퓨터 시스템, 원격 애플리케이션, 및/또는 원격 데이터베이스와 같은 외부 소스와 데이터를 교환할 수 있다.
컴퓨터 시스템(720)는 네트워크 인터페이스(753)를 포함하며, 이 네트워크 인터페이스를 통해 컴퓨터 시스템(720)은 외부 소스로부터 데이터를 수신하거나 데이터를 외부 소스에 전송한다. 도 1에 도시된 바와 같이, 네트워크 인터페이스(753)는 링크(751)를 통한 원격 컴퓨터 시스템(783)과의 데이터 교환을 용이하게 한다. 네트워크 인터페이스(753)은 예컨대 네트워크 인터페이스 카드 및 대응 NDIS(Network Driver Interface Specification) 스택과 같은 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 논리적으로 나타낼 수 있다. 링크(751)는 네트워크의 부분(이더넷 세그먼트)을 나타내고, 원격 컴퓨터 시스템(783)은 네트워크의 노드를 나타낸다.
마찬가지로, 컴퓨터 시스템(720)은 입/출력 인터페이스(746)를 포함하며, 이 입/출력 인터페이스를 통해 컴퓨터 시스템(720)은 외부 소스로부터 데이터를 수신하고 데이터를 외부 소스에 전송한다. 입/출력 인터페이스(746)는 데이터 링크(759)를 통해 모뎀(754)(예컨대, 표준 모뎀, 케이블 모뎀, 또는 디지탈 가입자 라인("DSL") 모뎀)에 연결되며, 이를 통해 컴퓨터 시스템(720)은 외부 소스로부터 데이터를 수신하고 데이터를 외부 소스에 전송한다. 도 7에 도시된 바와 같이, 입/출력 인터페이스(746) 및 모뎀(754)은 링크(752)를 통한 원격 컴퓨터 시스템(793)과의 데이터 교환을 용이하게 한다. 링크(752)는 네트워크의 부분을 나타내고, 원격 컴퓨터 시스템(793)은 네트워크의 노드를 나타낸다
도 7은 본 발명에 적합한 동작 환경을 나타내나, 본 발명의 원리는 본 발명의 원리를 구현할 수 있는, 필요한 경우 적절히 수정되는, 임의의 시스템 내에 구현될 수 있다. 도 7에 예시된 환경은 단지 예시적인 것이며, 본 발명의 원리를 구현할 수 있는 다양한 환경의 아주 작은 부분까지도 나타내고자 하는 것은 아니다.
본 발명은 그 사상 또는 필수적인 특징으로부터 벗어나지 않고서도 다른 특정 형태로 구현될 수 있다. 상기 설명된 실시예는 모든 측면에서 예시적이고 비제한적인 것으로만 고려되어야 한다. 따라서, 본 발명의 범위는 상기한 설명에 의해서가 아닌 청구의 범위에 의해서 나타내어진다. 청구의 범위의 등가물의 의미 및 범위 내에 속하는 모든 변화는 본 발명의 범위 내에 포함되어야 한다.