< D FB4D9B1B9BEEE20C0FCC0DABFECC6ED20C1D6BCD220C7ECB4F F B204D59204A4D2E687770>

Size: px

Start display at page:

Download "< D FB4D9B1B9BEEE20C0FCC0DABFECC6ED20C1D6BCD220C7ECB4F F B204D59204A4D2E687770>"

서웅 공
6 years ago
Views:

1 개정일 : 2013 년 10 월 10 일 T T A S t a n d a r d 다국어전자우편주소헤더 Internationalized Headers

3 서문 1. 표준의목적 본표준의목적은 non-us-ascii 글자가포함된다국어전자우편주소송수신을위한전자우편주소헤더를정의하는것이다. 2. 주요내용요약 전자메일의완전한국제화를위해요구되는것이 non-ascii 콘텐츠전송능력, 선택된정보의특정헤더필드인코딩능력, 그리고 non-ascii 글자의엔벨로프사용능력에국한되지는않다. 이런능력들을토대로해당정보와주소를메일헤더필드에표현할수도있어야한다. 본표준에서는 ASCII 대신 UTF-8로인코딩된 Unicode를인터넷이메일헤더필드의기본형식으로사용할수있는인터넷메일실험변형을수록한다. 3. 표준적용산업분야및산업에미치는영향 본표준은국내다국어전자우편주소체계가구축되어나가는데발생할수있는혼란을최소화하고일련의기술의발전과관련응용서비스활성화에기여할것이다. 또한다국어전자우편주소에대한신뢰성을확보하여전자우편주소시장을자연스럽게활성화시켜나갈것이다. 4. 참조표준 ( 권고 ) 4.1. 국외표준 ( 권고 ) - IETF RFC 6532, Internationalized Headers, 국내표준 - 해당사항없음 5. 참조표준 ( 권고 ) 과의비교 5.1. 참조표준 ( 권고 ) 과의관련성 본표준은참조표준 RFC 6532 을완전히수용한다. i

4 5.2. 참조한표준 ( 권고 ) 과본표준의비교표 RFC 6532 비고 1. 머리말 1. Introduction 동일 ( 번역 ) 2. 이표준에서사용하는용어 2. Terminology Used in This Specification 동일 ( 번역 ) 3. 메시지헤더필드변경 3. Changes to Message Header Fields 동일 ( 번역 ) 4. 보안고려사항 4. Security Considerations 동일 ( 번역 ) 5. IANA 고려사항 5. IANA Considerations 동일 ( 번역 ) 6. 감사의말씀 6. Acknowledgements 동일 ( 번역 ) 7. 참고문헌 7. References 동일 ( 번역 ) 6. 지적재산권관련사항 본표준의 지적재산권확약서 제출현황은 TTA 웹사이트에서확인할수있다. 본표준을이용하는자는이용함에있어지적재산권이포함되어있을수있으므로, 확인후이용한다. 본표준과관련하여접수된확약서이외에도지적재산권이존재할수있다. 7. 시험인증관련사항 7.1. 시험인증대상여부 - 해당사항없음 7.2. 시험표준제정현황 - 해당사항없음 8. 표준의이력정보 8.1. 표준의이력 판수제정 개정일제정 개정내역 제 1 판 제 2 판 제정 TTAK.IF-RFC5335 개정 ii

5 8.2. 주요개정사항 TTAK.IF-RFC5335 비고 1. 머리말 1. 개요 수정 2. 표준의구성및범위 삭제 2. 이표준에서사용하는용어 3. 용어정의 수정 3. 메시지헤더필드변경 4. 메시지헤더필드변경 수정 4. 보안고려사항 5. 보안고려사항 수정 5. IANA 고려사항 6. IANA 고려사항 동일 6. 감사의말씀 추가 7. 참고문헌 7. 참조 수정 iii

6 Preface 1. Purpose of Standard The purpose of this standard to define headers type for international addresses so an original recipient address with non-us-ascii characters. 2. Summary of Contents Full internationalization of electronic mail requires not only the capabilities to transmit non-ascii content, to encode selected information in specific header fields, and to use non-ascii characters in envelope addresses, But also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. 3. Applicable Fields of Industry and its Effect This standard facilitates the interoperability of process in the Address Internationalized System, and to support the international compatability, this standard specifies certificate profile for Address Internationalized System. 4. Reference Standards(Recommendations) 4.1. International Standards(Recommendations) - IETF RFC 6532, Internationalized Headers, Domestic Standards - None 5. Relationship to Reference Standards(Recommendations) 5.1. Relationship of Reference Standards(recommendations) This standard fully adopts RFC6530. iv

7 5.2. Differences between Reference Standard(recommendation) and this Standard RFC 6532 Remarks 1. Introduction 1. Introduction equivalent (translated) 2. Terminology Used in This Specification 3. Changes to Message Header Fields 2. Terminology Used in This Specification 3. Changes to Message Header Fields equivalent (translated) equivalent (translated) 4. Security Considerations 4. Security Considerations equivalent (translated) 5. IANA Considerations 5. IANA Considerations equivalent (translated) 6. Acknowledgements 6. Acknowledgements equivalent (translated) 7. References 7. References equivalent (translated) 6. Statement of Intellectual Property Rights IPRs related to the present document may have been declared to TTA. The information pertaining to these IPRs, if any, is available on the TTA Website. No guarantee can be given as to the existence of other IPRs not referenced on the TTA website. And, please make sure to check before applying the standard. 7. Statement of Testing and Certification 7.1. Object of Testing and Certification - None 7.2. Standards of Testing and Certification - None 8. History of Standard 8.1. Change History Edition Issued date Outline The 1st edition The 2nd edition Established TTAK.IF-RFC4952 Revised v

8 8.2. Revisions TTAK.IF-RFC5335 Remarks 1. Introduction 1. Introduction modified 2. Constitution and Scope excluded 2. Terminology Used in This Specification 3. Terms and Definitions modified 3. Changes to Message Header Fields 4. Changes to Message Header Fields modified 4. Security Considerations 5. Security Considerations modified 5. IANA Considerations 6. IANA Considerations equivalent 6. Acknowledgements added 7. References 7. References modified vi

9 목차 1. 머리말 1 2. 이표준에서사용하는용어 2 3. 메시지헤더필드변경 UTF-8 구문및정규화 RFC5322에대한구문확장 Message-IDs에서 8 비트 UTF-8 사용 행길이제한에대한영향 MIME 메시지유형인코딩제한에대한변경 MIME 인코딩된워드사용 message/global 미디어유형 5 4. 보안고려사항 7 5. IANA 고려사항 7 6. 감사의말씀 8 7. 참고문헌 규범참고문헌 정보참고문헌 9 vii

10 Contents 1. Introduction 1 2. Terminology Used in This Specification 2 3. Changes to Message Header Fields UTF-8 Syntax and Normalization Syntax Extensions to RFC Use of 8-bit UTF-8 in Message-IDs Effects on Line Length Limits Changes to MIME Message Type Encoding Restrictions Use of MIME Encoded-Words The message/global Media Type 5 4. Security Considerations 7 5. IANA Considerations 7 6. Acknowledgements 8 7. References Normative References Informative References 9 viii

11 다국어전자우편주소헤더 (Internationalized headers) 정보통신단체표준 ( 국문표준 ) 1. 머리말 인터넷메일은전송에서메시지를구별하며메시지를헤더와본문사이에서더욱구분한다 ([RFC5322]). 인터넷메일헤더필드값은사용자가볼수있도록한다양한문자열을포함한다. 이런문자열을지원문자범위는원래 7 비트형태의 [ASCII] 로제한되었다. MIME([RFC2045], [RFC2046], [RFC2047]) 은추가문자세트사용역량을제공하지만, 이지원은본문부분의데이터와헤더필드값의제한된곳에서만허용되는특별한인코딩된워드구조에만제한된다. 인터넷의국제화는메일주소와대부분의헤더필드값모두에서유니코드 ([RFC5198]) 가제공하는더큰문자세트의지원을요구한다. 추가적으로인코딩된워드와같이복잡한인코딩체계는비효율성뿐만아니라오류처리를위한상당한기회를내놓는다. 마지막으로이제대부분의시스템은 UTF-8 문자세트 (charset) 를자연스럽게지원한다. 따라서인터넷메일이 UTF-8([RFC3629]) 을직접지원하는것이매우바람직하다. 이문서는인터넷메시지포맷 ([RFC5322]), 그리고메일주소를포함하여헤더필드값에 ASCII만을사용하는것보다 UTF-8의직접사용을허용하는 MIME에대한개선을명시한다. 이확장포맷을사용하는메시지를위해새로운미디어유형인 message/global이정의된다. 이표준은 message/global 부분이기존메일인프라에걸쳐안전하게전송될수있도록메시지최상위유형의모든서브유형에서비식별 (non-identity) content-transfer-encodings를갖는것에대한 MIME 제한또한해제한다. 이표준은 UTF-8을위한자연적인종단간 (end-to-end) 지원모델을기반으로하며, 전송시스템이보장하는 8 비트클린 (8-bit-clean) 환경을갖는것에따라다르다. 리거시 7 비트인프라를통과하는전달을위한지원과 7 비트수신자에의한처리를위한지원은이표준이제공하지않는추가적인메커니즘을필요로한다. 이표준은 [RFC5335] 의개정인동시에대체표준이다. [RFC6530] 의 6 절은이표준과이전버전사이의접근법변화를설명한다. 1

12 2. 이표준에서사용하는용어 평문 ASCII 문자열은 [RFC5321] 및 [RFC5322] 와완전호환이다. 이문서에서비 ASCII 문자열은, 하나이상의 <UTF8-non-ascii> 를포함하는헤더필드값에있는경우 UTF-8 문자열이다 (3.1 절참조 ). 달리명시하지않은경우여기사용한모든용어는 [RFC5321], [RFC5322], [RFC6530] 또는 [RFC6531] 의정의를따른다. 이문서의핵심어 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY 및 OPTIONAL 은 [RFC2119] 의설명에따라해석해야한다. 8 비트 라는용어는 0x7F 를초과하는값으로데이터에있는옥텟을의미한다. 3. 메시지헤더필드변경 필드값에비ASCII 유니코드를허용하기위해 [RFC5322] 의헤더를정의가새로운포맷을지원하도록확장되었다. 후속절은 RFC 5322의 ABNF에대한필요한변경을명시한다. 아래에서언급하지않은구문규칙은 [RFC5322] 의정의를따른다. 이표준은헤드필드이름정의에대한 RFC 5322의규칙은변경하지않음에주목한다. 헤더필드본문이유니코드문자를포함하는것은허용되지만헤더필드이름자체는반드시 ASCII 문자만으로구성되어야한다. 이포맷의메시지는 SMTP를통해전송될 SMTPUTF8 확장 ([RFC6531]) 의사용을필요로함에도주목해야한다 UTF-8 구문및정규화 UTF-8 문자는 [RFC3629] 에서발췌한다음 ABNF([RFC5234]) 를사용하여옥텟으로정의할수있다. UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = <RFC3629 의 4 절에서정의 > 2

13 UTF8-3 = <RFC3629 의 4 절에서정의 > UTF8-4 = <RFC3629의 4 절에서정의 > 유니코드정규화에대한설명은 [RFC5198] 을참조한다. 정규화형식 NFC([UNF]) 을사용해야한다 (SHOULD). 실제로국제화를올바르게하려고하는경우가장자주언급하는목적중의하나는사람들이자신의이름철자를올바르게말할수있게하는것이다. 많은우편함로컬부분이개인이름을반영하기때문이이런원칙은우편함에도적용된다. NFKC 정규화형식 ([UNF]) 을사용하지않아야한다 (SHOULD NOT). 이형식을사용하면일부생소한상황에서어떤이름의철자를올바르게말하는데필요한정보를상실할수있기때문이다 RFC 5322 에대한구문확장 다음규칙은 UTF-8 콘텐츠를허용하기위해 [RFC5322] 과 [RFC5234] 에정의된 ABNF 구문을확장한다. VCHAR =/ UTF8-non-ascii ctext =/ UTF8-non-ascii atext =/ UTF8-non-ascii qtext =/ UTF8-non-ascii text =/ UTF8-non-ascii ; 본문을 UTF-8로업그레이드한다. dtext =/ UTF8-non-ascii 이런변경은이제다음구조가 UTF-8 을허용함을의미한다. 가. 헤더필드에서사용되는구조화되지않은텍스트 ( 예 : Subject: 또는 Content-description: ). 나. 원소를사용하는모든구조 ( 주소의로컬부및 Message-IDs 등을포함 ). 이것은 Received: 헤더필드의 for 에있는주소를포함한다. 다. 인용문자열. 3

14 라. 도메인. 헤더필드이름은이목록에없다는점에주목한다. 이들은여전히 ASCII로제한된다 Message-IDs 에서 8 비트 UTF-8 사용 Message-ID 생성알고리즘구현자는출력을 ASCII로제한하는것을선호할수있다 [MAY]. 이렇게제한하는것은일부발신자는다국어주소를사용하고나머지는그렇지않는메일링리스트스레드에서 In-reply-to: 와 References: 헤더필드를구성할때와같이어느정도장점이있기때문이다 행길이제한에대한영향 [RFC5322] 의 절은행을 998자로제한하며행을 78자로만제한할것을권고한다. 이표준은이전제한을 998 옥텟으로변경한다. ( 참고 : ASCII에서는옥텟과문자가결과적으로동일하지만 UTF-8에서는그렇지않다.) 78자제한은문자측면에서정의된상태를유지하지만옥텟측면에서는그렇지않은데행길이문제가아니라표시너비문제를다루기위한것이기때문이다 MIME 메시지유형인코딩제한에대한변경 이표준은 [RFC2045] 의 6.4 절을갱신한다. [RFC2045] 는 message/ 의서브유형에대한 content-transfer-encoding의적용을금지한다. 이표준은이규칙을완화한다. content-transfer-encoding을허용하기위해새로정의된 MIME types 유형을허용하며 message/global에대해 content-transfer-encoding을허용한다 (3.7 절참조 ). 배경 : 일반적으로 message/global 전송은 8 비트클린채널에서실시되고본문부분은 식별 (identity) 인코딩을갖게된다 ( 즉, 디코딩이필요하다 ). 하지만 message/global을포함하는메시지가 [RFC6152] 에서설명한것처럼 8 비트에서 7 비트로다운그레이드되는경우, 메시지에인코딩을적용해야만할수있다. 메시지가 7 비트환경과이런확장을구현한환경사이를여러번이동하면다중수준의인코딩이발생할수있다. 실제로는좀처럼보이지않을것으로예상되며이문제를처리하는다른방법의잠재적복잡성이필요한경우내포된인코딩의허용복잡성보다더클것으로생각된다. 4

15 3.6. MIME 인코딩된워드사용 MIME 인코딩된워드기능 ([RFC2047]) 은비ASCII 텍스트를두는역량을제공하지만이확장에서허용하는서브세트에만둘수있다. 추가적으로인코딩된워드는사실상더복잡한데임의의문자세트사용을허용하기때문이다. 따라서이확장을사용하는메시지용헤더필드를생성할때에는인코딩된워드를사용하지않아야한다 [SHOULD NOT]. 다른메시지의자료를수용할때에이전트는인코딩된워드사용을 UTF-8의직접사용을변환해도된다 [MAY]. 인코딩된워드를디코딩할때에는주의해야하는데인코딩된워드를디코딩된동등한 UTF-8로교체한후의결과는구문상유효하지않을수있기때문이라는점에주목한다. 인코딩된워드를디코딩하도록선택한프로세서는구문상유효하지않은필드를절대생성하지않아야한다 [MUST NOT] message/global 미디어유형 이포맷의다국어메시지는반드시 [RFC6531] 에의해인증된것으로또는이런메시지를지원하는비SMTP 환경내에서만전송되어야한다 [MUST]. 다음의경우메시지는 message/global message 이다. o 이문서에명시된대로 8 비트 UTF-8 헤더값을갖거나 o 본문부분의헤더필드에 8 비트 UTF-8 값을갖는다. 달리명시하지않은경우 message/global 부분의콘텐츠는 message/rfc822 부분의콘텐츠와동일하다. 이유형의객체를 7 비트전용시스템에전송해야하는경우적절히적용된 content-transfer-encoding이반드시있어야한다 [MUST]. (message/global을인식하지못하는 MIME 호환시스템은이것을 [RFC2046] 의 절의설명과같이 application/octet-stream 으로취급할것으로가정한다는점에주목한다.) 등록은다음과같다. 메시지이름 : message 서브유형이름 : global 필요파라미터 : 없음 5

16 옵션파라미터 : 없음 인코딩고려사항 : 모든 content-transfer-encoding이허용된다. 허용되는경우 8 비트또는바이너리 content-transfer-encodings을권장한다. 보안고려사항 : 4 절을참조상호운영성고려사항 : 이미디어유형은다국어전자우편헤더를갖는전자우편메시지에대해 message/rfc822 콘텐츠유형과유사한기능을제공한다. 이런콘텐츠를다른메시지에끼워넣거나반송할필요가있는경우, 일반적으로이미디어유형을사용하고콘텐츠를변경없이두거나콘텐츠를 message/rfc822로하향변환 (down-convert) 하는옵션이있다. 이선택각각은설치된기반과그러나다른속성과상호작용할것이다. 다국어헤더를인식하지못하는시스템은일반적으로 message/global 본문부분을알수없는첨부로취급할것이나 message/rfc822 구조는이해할것이다. 하지만 message/global을이해하는시스템은 message/rfc822로의하향변환결과에비해우월한기능을제공할것이다. 가장상호운영성이있는선택은배치된소프트웨어에의해결정된다. 공시표준 : RFC 6532 이미디어유형을사용하는애플리케이션 : multipart/report 생성또는파싱을지원하는 SMTP 서버및전자우편클라이언트. 다국어헤더를갖는메시지를첨부로전달하는전자우편클라이언트. 추가정보 : 매직넘버 : 없음 파일확장자 : 확장자.u8msg 를권장한다. Macintosh 파일유형코드 : public.utf8- -message 의유니폼유형식별자 (UTI: uniform type identifier) 를권장한다. 이것은 public.message 및 public.composite-content 와부합하지만 public.utf8-plain-text 와부합하지는않는다. 추가정보문의담당자및전자우편주소 : 본문서의작성자주소절참조. 용도 : 일반 6

17 사용제한 : 이것은다른 MIME 미디어유형을끼워넣는구조화된미디어유형이다. 이미디어유형이 7 비트전용전송으로전송되지않는한 8 비트또는바이너리 content-transfer-encoding을사용해야한다 [SHOULD]. 작성자 : 본문서의작성자주소절참조. 변경통제자 : IETF 표준프로세스 4. 보안고려사항 UTF-8은종종여러옥텟을단일문자로인코딩하는것을필요로하기때문에국제화는 ( 일반적으로 ) 헤더필드값과 ( 특히 ) 메일주소가길어지게할수있다. [RFC5322] 에명시된것처럼각문자행은 CRLF를제외하고 998 옥텟을절대초과해서는안된다 [MUST]. 반면전자우편주소또는로컬부분을파싱, 저장또는처리하는 MDA( 메일전달에이전트 ) 는버퍼오버플로우, 주소잘림또는저장소할당초과가발생하지않도록반드시각별히주의해야한다. 또한비교시주소의전체길이를사용하도록반드시각별히주의해야한다. UTF-8을사용하여표시되는특수문자또는문자그룹과동등한또는유사한것을표시하는많은방법이있다. 이것이초래할수있는문제에대한자세한사항은 [RFC3629] 의보안고려사항을참조한다. 이런문제를최소화하기위해 3.1 절에서설명한정규화과정을권장한다. 도메인키식별메일 (DKIM, Domain Keys Identified Mail), S/MIME 및 OpenPGP 등과같은전자우편서명시스템에대한 UTF-8 헤더의보안영향은 [RFC6530] 의 14 절에설명되어있다. 어떤사용자가비ASCII 우편함주소와 ASCII 우편함주소를갖는경우해당사용자를식별하는전자인증서는신원증명서 (identity) 에두주소를모두가질수있을것이다. 단일인증서에여러전자우편주소를신원증명서로갖는것은이미 PKIX(Public Key Infrastructure using X.509, X.509를이용한공개키인프라 ) 및 OpenPGP([RFC3156]) 에서이미지원되지만이문맥에서주소에 UTF-8의도입과관련된사용자인터페이스문제가있을수있다. 5. IANA 고려사항 IANA는 3.7 절에포함된등록양식을사용하여 message/global MIME 유형의등록을갱신했다. 7

18 6. 감사의말씀 비록초기저작물에서많은상세사항이변경되었지만이문서는 Paul Hoffman의초안문서에처음기술된많은아이디어를수용하고있다. 작성자들은이전버전의편집에대한 Jeff Yeh의노력과공헌에특별히감사를표한다. 이문서의대부분의내용은 John C Klensin과 Dave Crocker가제공했다. Martin Duerst, Julien Elie, Arnt Gulbrandsen, Kristin Hubner, Kari Hurtta, Yangwoo Ko, Charles H. Lindsey, Alexey Melnikov, Chris Newman, Pete Resnick, Yoshiro Yoneya 그리고 JET(Joint Engineering Team) 의추가구성원이상당한코멘트와제안을했으며이문서에수용했다. 작성자들은이모든사람들에게그공헌에대해진심으로감사를표한다. 7. 참고문헌 7.1. 규범참고문헌 [ASCII] Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4, [RFC2119] Bradner, S., Key words for use in RFCs to IndicateRequirement Levels, BCP 14, RFC 2119, March [RFC3629] Yergeau, F., UTF-8, a transformation format of ISO 10646, STD 63, RFC 3629, November [RFC5198] Klensin, J. and M. Padlipsky, Unicode Format for NetworkInterchange, RFC 5198, March [RFC5234] Crocker, D. and P. Overell, Augmented BNF for Syntax Specifications: ABNF, STD 68, RFC 5234, January [RFC5321] Klensin, J., Simple Mail Transfer Protocol, RFC 5321, October [RFC5322] Resnick, P., Ed., Internet Message Format, RFC 5322, October

19 [RFC6530] Klensin, J. and Y. Ko, Overview and Framework for Internationalized , RFC 6530, February [RFC6531] Yao, J. and W. Mao, SMTP Extension for Internationalized , RFC 6531, February [UNF] Davis, M. and K. Whistler, Unicode Standard Annex #15: Unicode Normalization Forms, September 2010, < 정보참고문헌 [RFC2045] Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November [RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, RFC 2046, November [RFC2047] Moore, K., MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text, RFC 2047, November [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, MIME Security with OpenPGP, RFC 3156, August [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 5280, May [RFC5335] Yang, A., Internationalized Headers, RFC 5335, September [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, SMTP Service Extension for 8-bit MIME Transport, STD 71, RFC 6152, March

20 저자주소 Abel Yang TWNIC 4F-2, No. 9, Sec 2, Roosevelt Rd. Taipei 100 Taiwan Phone: ext abelyang@twnic.net.tw Shawn Steele Microsoft 전자우편 : Shawn.Steele@microsoft.com Ned Freed Oracle 800 Royal Oaks Monrovia, CA USA 전자우편 : ned+ietf@mrochek.com 10

21 표준작성공헌자 표준번호 : 이표준의제정 개정및발간을위해아래와같이여러분들이공헌하였습니다. 구분성명위원회및직위 연락처 ( 등 ) 소속사 표준 ( 과제 ) 제안정유경인터넷주소자원 PG 위원 ykjung@kisa.or.kr 한국인터넷진흥원 표준초안작성자 표준초안에디터 표준초안검토 김경석인터넷주소자원 PG 위원 gimgs0@gmail.com 부산대 정유경인터넷주소자원 PG 위원 ykjung@kisa.or.kr 한국인터넷진흥원 김경석인터넷주소자원 PG 위원 gimgs0@gmail.com 부산대 정유경인터넷주소자원 PG 위원 ykjung@kisa.or.kr 한국인터넷진흥원 유승화인터넷주소자원 PG 의장 swyoo@ajou.ac.kr 아주대학교 외프로젝트그룹위원 표준안심의 민경선전송통신기술위원회의장 Minks808@paran.co m 외기술위원회위원 KTCS 사무국담당 박정식통신융합부부장 TTA 오구영통신융합부책임 TTA 11

22 정보통신단체표준 ( 국문표준 ) 다국어전자우편주소헤더 (Internationalized Headers) 발행인 : 한국정보통신기술협회회장발행처 : 한국정보통신기술협회 , 경기도성남시분당구분당로 47 Tel : , Fax : 발행일 :

Microsoft Word - TTAK.KO

Microsoft Word - TTAK.KO d 정보통신단체표준 ( 국문표준 ) 제정일 : 2014 년 4 월 10 일 T T A S t a n d a r IPTV 환경에서의이어보기서비스요구사항 Seamless Play Service Requirement for IPTV 제정일 : 2014 년 4 월 10 일 IPTV 환경에서의 이어보기서비스요구사항 Seamless Play Service Requirement