투고 스타일

Posting style
인터넷 포럼 스레드의 가시성을 높이기 위한 게시 방법은 범프(인터넷)를 참조하십시오.

전자 메일, 인터넷 포럼 또는 Usenet에서 메시지에 회신할 때 원본은 다양한 게시 스타일에 포함되거나 "인용"될 수 있습니다.

주된 옵션은 인터리브 투고(인라인 응답이라고도 불리며, 응답의 다른 부분이 원래 투고의 관련 부분에 이어집니다), 하단 투고(따옴표 뒤에 응답이 인용된 원본 메시지 앞에 있습니다) 또는 상단 투고(따옴표 뒤에 응답이 인용된 원본 메시지 앞에 있습니다.이러한 옵션 각각에 대해 원본 텍스트의 트리밍이 허용되는지, 필수인지 또는 선호되는지에 대한 문제도 있습니다.

오랫동안 전통적인 스타일은 아래에 인용된 원문의 답안을 최대한 많이 게시하는 것이었다(아래 또는 인라인).몇 년 후, 비즈니스 커뮤니케이션에 이메일이 보급되었을 때, 원문 전체보다 위에 답장하고, 답장 아래에 남겨두는 것이 널리 행해지고 있습니다(아마도 손대지 않았을 것입니다).

각 온라인 커뮤니티는 어떤 스타일이 적절하고 받아들일 수 있는지에 대해 다르지만, 일부 커뮤니티에서는 "잘못된" 방법을 사용하는 것이 에티켓 위반으로 보일 위험이 있으며 커뮤니티 단골들로부터 격렬한 반응을 불러일으킬 수 있습니다.

이전 메시지 인용

전자 메일 회신에서는, 응답하는 원래의 메시지의 전체 또는 일부를 포함하는 것이 적절할 수 있습니다.인터넷 통신의 비동기적인 성질 때문에, 많은 사람들이 동시에 대화를 하고, 원래의 메시지가 송신된 후에 전자 메일 응답을 수신하는 경우가 있습니다.이러한 이유로 원본 포스터는 게시물이 어떤 메시지에 응답해야 하는지 알지 못할 수 있으며, 컨텍스트를 제공하는 것이 도움이 됩니다.많은 전자 메일 읽기 프로그램(메일 사용자 에이전트)은 회신 편집 창에 원본 메시지의 복사본을 자동으로 포함시킴으로써 이러한 동작을 장려합니다.

이전 메시지에서 따옴표로 묶인 텍스트는 보통 새로운(응답) 텍스트와 구별됩니다.종종 두 부분에 서로 다른 움푹 패인 곳이 있습니다.다음 예제에서는 첫 번째 행이 원본 메시지이고 두 번째 행이 응답입니다.

네가 이런 말을 하다니 믿을 수가 없어.이 모든 단어들은 끔찍하다.그들은 상처를 입어서 말이 안 된다.-Doc Evil
당신의 글과 매우 흡사합니다.

또는 특수 딜리미터 행을 사용할 수도 있습니다.

이봐, 조, 파리는 영국이 아니라 프랑스에 있어. - 메리
--- 오리지널 메시지 --- 방금 영국에서, 파리에서 전화가 왔는데요.- 오리지널 메시지의 끝 ---

보다 명확한 설명을 위해 두 부품 사이에 빈 선을 삽입할 수도 있습니다.텍스트 마크업을 지원하는 이메일 매체(HTML이나 RTF 등)를 사용할 경우 이전 텍스트는 고유한 글꼴 및/또는 색상으로 표시될 수 있습니다.

    회의는 다음 주 금요일로 연기되었다.--메리 
보고서 마감도 앞당겨졌나요?-Joe

따옴표로 묶인 회선 프리픽스

Microsoft Outlook에서 지원하는 다른 이메일 견적 스타일
다음 항목도 참조하십시오.사용자 인터넷 견적

일반 텍스트 전자 메일의 일반적인 규칙은 따옴표로 묶인 텍스트의 각 행 앞에 고유한 문자 또는 문자열을 붙이는 것입니다.2020년 현재(그리고 이전 수년간)에는 더 큰 기호(')가 있습니다.> 표준 프리픽스)[1]는 거의 일반적으로 사용되고 있습니다만, ASCII 세로 막대 문자등의 문자( 「」)가 사용되고 있습니다. 따옴표로 둘러싸인 텍스트마커 앞이나 뒤에 공백이 하나 이상 삽입되는 경우도 있습니다.

하나의 인용 프리픽스가 올바르고 다른 인용 프리픽스가 틀렸다고 선언하는 표준은 없지만, 일부 표준은 기존 인용에 의존합니다.「발행하지 않았다」라고 하는, 낡은 「1036년의 아들」의 초안 RFC 1849에서는, 다음과 같이 권장하고 있습니다.>RFC 3676은 이에 의존하여 고려되고 있습니다.>> " 및 "> > "는 의미론적으로 다릅니다.즉, ">> <고객명> 님의 견적 내용은 2개입니다만, <고객명> 님은> > 에는, 「>」로 시작하는 행을 따옴표로 둘러싸는 따옴표로 둘러싸인 1이 있습니다.그러나 대부분의 전자 메일클라이언트는 두 시퀀스를 동등하게 취급합니다.

인용 규칙은 1990년까지 Usenet 뉴스그룹에서 보편화되었으며, 기본적으로 또는 사용자가 설정할 수 있는 옵션으로서 많은 인기 있는 이메일 인터페이스에서 지원됩니다.예를 들어, Microsoft Outlook 에서는, 이 동작은 「원래의 각 행의 프리픽스」라고 하는 옵션에 의해서 제어됩니다.따옴표로 둘러싸인 행에 마커를 자동으로 삽입하는 것 외에 일부 인터페이스에서는 "로 시작하는 행이>" 문자 또는 유사한 문자는 따옴표로 묶인 텍스트로 구분된 글꼴 또는 색상으로 자동으로 표시됩니다.

보고서는 어떻게 되어가고 있나요?--메리 정오까지는 책상 위에 있을 겁니다.--조

따옴표로 묶인 선 마커를 삽입하면 원래 한 줄이 응답에서 두 줄로 접혀져 연속선에 적절한 마커가 없을 수 있습니다.이러한 경우 모호함을 피하기 위해 인용된 텍스트의 각 블록 뒤에 공백 행을 삽입하는 것을 고려할 수 있습니다.

 이사회가 다시 판매 데이터를 요구하고 있습니다.우리는 정말 제공해야 한다.> 몇 가지 수치와 함께.보고서는 어떻게 되어가고 있습니까?-메리 
정오까지는 책상 위에 있을 겁니다.-조

따옴표로 둘러싸인 라인 마커는 보통 일반 텍스트메시지에서 사용됩니다.HTML 메시지에서는 따옴표로 둘러싸인 텍스트를 나타내기 위해 다음과 같은 HTML 들여쓰기 요소를 사용할 수 있습니다.blockquote또는dl.

회신 수준 표시

메시지에는 종종 이전 긴 토론 라운드에서 교환된 두 개 이상의 메시지 텍스트가 포함됩니다.기존 마커를 제거하지 않고 매 라운드마다 추가 따옴표 마커를 삽입하면 각 행의 선두에 있는 마커 수에 응답의 "레벨", 즉 해당 행이 작성된 후 라운드가 몇 번 발생했는지 표시됩니다.이러한 축적된 마커는 보통 각 메시지에서 온 부분을 식별하기에 충분합니다.일부 전자 메일 인터페이스는 이 규칙을 인식하고 각 수준을 자동으로 다른 색으로 렌더링합니다.예를 들어 다음과 같습니다.

리포트는 어떻게 되어가고 있습니까?- Mary정오까지는 책상 위에 있을 겁니다.-Joe조 씨, 늦어도 11시까지는 필요합니다.- 메리 
네, 하지만 이번 달 수치는 빠집니다.-조

토론이 두 당사자 간에만 있는 경우 짝수 마커(0 포함)는 송신자가 작성한 텍스트를 나타내고 홀수 마커 수는 수신자가 작성한 텍스트를 나타냅니다(위의 예에서는 짝수 숫자는 Joe 텍스트, 홀수 숫자는 Mary 텍스트). 

문제 없어요.그럼 오후 6시다.-짐
수요일 오전 10시 1분에 대니는 이렇게 썼다. 5시 30분에 보고서를 이메일로 보내야 해요. 1시간만 뒤로 미룰 수 있을까요?--대니 >> 수요일 오전 9시 40분에 짐은 다음과 같이 썼다:>>> 오늘 밤 5시부터 약 30분 동안 메일 서비스를 정지합니다.-Jim

HTML 메시지에서는blockquote또는dl요소를 내포하여 동일한 효과를 얻을 수 있습니다.

어트리뷰션 라인

인용된 자료 앞에는 종종 그 작성자를 식별하는 속성 행이 붙습니다.이러한 행은, 복수의 당사자간의 논의에 특히 도움이 됩니다.예를 들어 다음과 같습니다.

  Nancy는 다음과 같이 썼다:퍼포먼스 수치는 언제 발표됩니까?> 테스트는 다음 주에 완료됩니다.  
  피터는 썼다:> 메리는 다음과 같이 썼다.오늘 만나서 마케팅 전략에 대해 논의해야 합니다.>잠깐만요,아직서해안판매데이터가없습니다. 
나도 피터 말에 동의해.우리는 판매 데이터와 낸시의 실적 수치가 필요합니다.다음 주 금요일 점심 후에 만나요.

이 답장은 낸시(피터에게 답장)와 피터(메리에게 답장)의 두 메시지를 인용합니다.

많은 메일 에이전트는 인용된 자료의 맨 위에 이러한 속성 행을 자동으로 추가합니다.새로 추가된 속성 행은 따옴표로 묶인 텍스트의 일부가 아니기 때문에 따옴표로 묶인 마커를 얻을 수 없습니다.따옴표로 묶인 행의 수준 표시기는 항상 대응하는 텍스트보다1개 작습니다.그렇지 않으면 리더와 선두 마커 수에 따라 텍스트 색상을 선택하는 전자 메일인터페이스가 혼동될 수 있습니다.

인용문 선두에 속성행 대신 괄호 안의 코멘트로 작성자를 나타낼 수 있습니다.

   [피터:] 퍼포먼스 수치는 언제 발표됩니까?> [낸시:]테스트는 다음 주에 완료됩니다. >> [ Mary : ]오늘 만나서 마케팅 전략에 대해 논의해야 합니다.[피터:]잠깐만요, 저희는 아직 서부 해안의 판매 데이터를 가지고 있지 않습니다. 
나도 피터 말에 동의해.판매 데이터와 낸시의 실적 수치가 필요합니다.다음 주 금요일 점심 후에 만나요.

Fidonet 및 일부 메일 사용자 에이전트에서 사용되는 또 다른 방법은 인용 마커 앞에 작성자의 이니셜을 배치하는 것입니다.이것은, 어트리뷰트 행의 유무에 관계없이 사용할 수 있습니다.

  낸시:N> Peter는 다음과 같이 썼다.퍼포먼스 수치는 언제 발표됩니까?테스트는 다음 주에 완료됩니다.  
  Peter는 썼다: P> Mary는 다음과 같이 썼다:오늘 만나서 마케팅 전략에 대해 논의해야 합니다.P>기다리는 것이 좋을 것 같습니다.서해안 판매 데이터는 아직 없습니다. 
나도 피터 말에 동의해.우리는 판매 데이터와 낸시의 실적 수치가 필요합니다.다음 주 금요일 점심 후에 만나요.

트리밍 및 재포맷

긴 토론(특히 뉴스그룹 토론)에 회신할 때 원래 메시지에서 인용된 텍스트는 회신과 관련된 부분만 또는 상기시키기 위해 종종 잘립니다.이 관행은 때때로 "트림 포스트" 또는 "편집 게시"라고 불리며 게시 [2]에티켓 매뉴얼에서 권장됩니다.

삭제된 텍스트의 표시기가 표시되는 경우가 있습니다.일반적으로 각 괄호로 묶인 태그의 형식은 "[sniped]", "trimed]", 또는 단순히 "[...]입니다.저장된 텍스트는 예를 들어 선을 다시 접어서 어느 정도 편집할 수 있습니다.예를 들어, 원래 메시지가

지난주 취소된 프로젝트 미팅이 오늘 14시 30분 정각에 3층 회의실에서 개최됨을 알려드립니다.모두 참석해야 한다.--메리

답변은 다음과 같다

  > 프로젝트 미팅 [...]는 오늘 3층에서 개최됩니다> 회의실 Mary, 그 방의 마이크를 확인해 주세요.-Joe

아니면 그냥

  3층 회의실 메리, 그 방의 마이크를 꼭 확인해 주세요.--Joe

삭제된 텍스트는 괄호 안의 요약으로 대체할 수도 있습니다.

  목요일에 짐은 이렇게 썼다:> 영화는 원작에는 없는 이야기에 분명히 위협감을 더한다.  [...어두운 톤이 영화를 약화시킨다고 주장...]그렇지 않아요어두운 톤이 잘 어울리는데, 일단 이해하면 두 사람은 서로 다른 청중을 겨냥하고 있다는 것을 알 수 있다.

자동으로 포함된 텍스트(서명 블록, 무료 전자 메일서비스 광고, 회사 면책사항 등)는 수동으로 작성된 텍스트보다 생략 없이 삭제될 가능성이 높습니다.일부 포스터는 원래 메시지에서 회신하지 않은 부분을 삭제할 수 있습니다.일부 포스터는 "종료"된 것으로 간주되는 문제를 다루는 부분만 삭제하고, 더 논의할 가치가 있거나 나중에 [citation needed]회신할 부분을 남깁니다.

어느 정도 잘라야 합니까?

일부 스타일 가이드에서는 일반적으로 인용된 응답 자료는 가능한 한 삭제하거나 요약하여 독자가 [2]답변을 이해할 수 있도록 하는 것이 좋습니다.물론 그것은 독자들이 토론에 대해 얼마나 알고 있다고 가정할 수 있느냐에 달려있다.특히 개인 이메일의 경우 제목 행이 충분한 경우가 많아 긴 [2]메시지의 일부 포인트에만 회신하지 않는 한 인용할 필요가 없습니다.

특히 이미 인용된 텍스트가 포함된 메시지에 회신할 때 인용된 자료가 여전히 관련이 있는지 고려해야 한다.예를 들어 다음과 같습니다.

>> [ Mary : ]오늘 오후에 만나서 마케팅 전략에 대해 논의해 주시겠습니까? >> [ Peter : ]필요한 모든 정보를 얻을 수 있다면요. > 서해안 판매 데이터는 아직 확보되지 않았습니까? 
LA 사무소에서 방금 보냈어요조.

메리의 메시지에서 인용한 내용은 피터의 답변과 관련이 있지만 조의 답변과는 관련이 없습니다.후자는 다음과 같이 다듬어질 수 있었다.

 서부 해안의 판매 데이터는 아직 확보되지 않았습니까?LA 사무소에서 방금 보냈어요조.

한편, 경우에 따라서는, 원래의 메세지의 트리밍이나 편집이 부적절할 수 있습니다.예를 들어, 원래 메시지를 보지 못한 제3자에게 응답을 복사하는 경우 전체를 인용하는 것이 좋습니다.그렇지 않으면 컨텍스트가 부족하기 때문에 잘린 메시지가 새 수신인에 의해 잘못 해석될 수 있습니다.

또, 고객이나 써플라이어에게 회답할 때는, 상대방이 그 카피를 보관하지 않았던 경우에 대비하여, 원래의 메세지 전체를 인용하는 것을 추천합니다.

회답의 배치

인터리브 스타일

인터리브 응답 스타일(「인라인 응답」, 「인터라인 응답」, 「포인트 바이 포인트 반박」, 또는 「보텀 투고」라고도 불린다)에서는, 원래의 메세지는 2개 이상의 섹션으로 분할되어 각각 특정의 응답 또는 코멘트가 뒤따릅니다.인라인 스타일의 응답에는 특정 포인트가 아닌 응답 메시지 전체에 적용되는 상위 포스트 또는 하위 포스트 코멘트가 포함될 수도 있습니다.예를 들어 다음과 같습니다.

저는 신제품 라인에 대한 논의를 따라가고 있습니다.제 생각은 이렇습니다. 
Joe는 다음과 같이 썼다.> 우리 회사의 가격은 경쟁력이 있습니까? 
지금으로서는 문제가 되지 않을 수도 있지만, 우리는 여전히 품질 우위를 점하고 있습니다. 서해안에는 충분한 훈련을 받은 인력이 없습니다. 많은 >의 신입사원이 있습니다만, 그들은 아직 저희 제품을 모릅니다. 
충돌 훈련 코스로 데려올 수 있어요 
Mary는 다음과 같이 썼다.> 우리는 아직 명확한 마케팅 계획을 가지고 있지 않다.  
피터, 네가 맡아줄래?도움이 필요하시면 말씀하세요. 
대체로 나는 꽤 낙관적이다.이번 분기 말 이전에 기본 시스템을 출하할 것 같습니다.낸시

인터리브 회신 스타일은 톱 포스트와 조합할 수도 있습니다.선택한 포인트는 위와 같이 인용되어 회신되며, 그 후 원본 메시지의 전체 복사본이 추가됩니다. 

1시간 후에 보고서를 제출할 수 있습니까? 
그래, 할 수 있어.요약은 늦어도 오후 5시까지는 보내드리겠습니다.짐.
수요일 오전 10시 1분에 Danny는 다음과 같이 썼다:>>> 오후 2시: 현재 보고서> Jim, 나는 그 시간에 회의가 있다. 보고서를 한 시간 후에 제출할 수 있습니까? >>> 오후 4시 30분: 피드백의 개요를 송신합니다> 또, 상기의 조작을 실시하면, 나중에 실시할 필요가 있는 경우도 있습니다. > Danny > > > 수요일 오전 9시 40분에 Jim은 다음과 같이 글을 올렸습니다.오늘의 스케줄은 다음과 같습니다.> 오전 10시 00분: 보고서 작성 데이터 수집 >> 오후 2시 00분: 팀에 보고서 제출 > 오후 4시 30분: 피드백 요약 전송 >>> Jim

인터리빙은 WWW가 존재하기 몇 년 전, 그리고 [3]이메일과 인터넷이 학계 밖으로 확산되기 전에 Usenet 토론 목록에서 가장 많이 사용되는 답변 스타일이었다.

인터리빙은 많은 인터넷 사용자들이 Usenet 뉴스그룹과 다른 인터넷 포럼에 노출되어 있었기 때문에 원래 이메일에서도 일반적이었다.[citation needed]이 스타일은 인터넷이 개방된 후 상업적이고 비학업적인 개인 [citation needed]용도로 이메일에 덜 보편화 되었다.그 [citation needed]이유 중 하나는 당시 현장에 들어온 캐주얼한 이메일 사용자가 많다는 것이다.다른 원인으로서는 일부 웹 메일 리더의 응답 기능에 의해 제공되는 불충분한 지원이 있습니다.이 기능은 원래 메시지의 복사본을 응답에 자동으로 삽입하지 않거나 프리픽스레벨 [citation needed]인디케이터 없이 실행됩니다.마지막으로 대부분의 포럼, Wiki 토론 페이지 및 블로그(Slashdot 등)는 기본적으로 모든 최신 메시지를 시간순으로 [citation needed]표시함으로써 맨 아래 포스트 형식을 사용합니다.인터리빙은 복잡한 스레드 내의 명확성이 [citation needed]중요한 기술 메일링 리스트에서 계속 사용됩니다.

톱 포스트

상단 게시 스타일에서는 원래 메시지가 문자 그대로 포함되며, 그 위에 답장이 표시됩니다.약어 TOUPHE('text over, full quote under')로 불리기도 합니다.Jeopardy! 응답 스타일이라고도 불리는데, 게임쇼의 대표적인 단서/응답 형식에서와 같이 답변이 질문 앞에 나옵니다.

예:

문제 없어요.그럼 오후 6시입니다.Jim 
------------------------------------------------------------------------------------------- 2007년 10월 16일 (화) 오전 10시 1분 수신인: Jim <jim@example.com> 제목: RE: Job Woa!  잠깐만요.  5시 30분에 주요 기술 직원에게 보고서를 발송하는 작업이 예정되어 있습니다.  한 시간만 뒤로 미룰 수 있을까요? Danny ----------------------------------------------------------------------------------------- 2007년 10월 16일(화) 오전 9시 40분 종료: Danny <danny@example.com> 제목: 오늘 밤 5시부터 약 30분간 메일 서비스를 중단하고 업데이트 및 중요한 수정 프로그램을 설치합니다. 짐

Top-Posting에서는 컨버세이션 내의 브랜치스크립트가 수정되지 않은 것으로 보입니다.대부분의 경우 모든 응답은 컨버세이션의 단일 브랜치 안에 있습니다.텍스트 맨 위에는 최신 응답이 표시됩니다.이는 이메일 스레드가 다른 사람에게 "공식"[citation needed] 기록이라고 믿게 만들 수 있는 비즈니스 서신에 유리하게 보입니다.

반면 인터리브 및 하단 게시물의 과도한 들여쓰기는 해석하기 어려울 수 있습니다.참가자가 매니저 대 사원, 컨설턴트 대 고객 등 위상이 다른 경우, 한 사람이 전체적인 맥락 없이 다른 사람의 말을 잘라내는 것은 무례하게 보이거나 [citation needed]오해를 불러일으킬 수 있다.

Usenet의 비공식 토론 초기에는 모두가 동등하게 권장되는 바닥 게시물이었다.1990년대 중반까지 net.newcomers 뉴스 그룹의 게시물은 인터리빙 응답을 고집했다.Usenet comp.lang 계층, 특히 comp.lang.c와 comp.lang.c++는 2010년대와 같은 것을 주장했다.alt 계층은 탑 포스트를 허용했습니다.새로운 온라인 참가자, 특히 Usenet의 경험이 한정되어 있는 사람들은 게시 스타일에 대한 논쟁에 덜 민감하게 반응하는 경향이 있다.

토론이 진행 중인 메일링 리스트에서 탑 포스트는 문제가 될 수 있으며, 결국 누군가가 탑 포스트 자료에 대해 행동해야 합니다.예를 들어, 톱 포스트에 "저러한 변경은 괜찮아 보입니다.계속해서 작성하세요"라고 하는 것은 매우 불편할 수 있습니다.이것은, 독자가 톱 포스트가 참조하고 있는 변경을 알기 위해서, 긴 E-메일 트레이스를 읽어낼 필요가 있기 때문입니다.이러한 경우 변경 내용을 설명하는 텍스트 바로 아래에 텍스트를 남겨두는 것이 훨씬 편리합니다.

스마트폰과 같은 모바일 기기 사용자는 탑 포스트를 사용할 것을 권장합니다. 왜냐하면 이 기기들은 보기 위해 메시지의 시작 부분만 다운로드 할 수 있기 때문입니다.나머지 메시지는 필요할 때만 가져오므로 다운로드 시간이 더 걸립니다.메시지 첫머리에 관련 콘텐츠를 배치하면 [4][5][6]대역폭, 시간 및 스크롤이 줄어듭니다.

상위 게시물은 Microsoft Outlook, Gmail 및 기타 많은 현재 이메일 리더에서 "응답" 기능의 동작의 자연스러운 결과입니다.기본적으로는 이러한 프로그램은 원래 메시지의 복사본을 회신 메시지에 삽입하고(헤더 없이 추가 들여쓰기 또는 따옴표 없이) 편집 커서를 그 위에 배치합니다.게다가 Microsoft Outlook 의 대부분의 플레이버에 있는 버그로 인해, HTML/RTF [citation needed]로 송신된 메시지에 플레인 텍스트로 회신하면, 인용 마커가 없어집니다.이러한 이유나 그 외의 이유로, 많은 유저가 톱 포스트를 「표준」응답 스타일로 받아들이고 있는 것 같습니다.

마이크로소프트의 영향도 있지만 메일링 리스트와 개인 이메일에 [7][8][9][10]탑 포스트가 매우 일반적입니다.

상단의 투고는 항상 서드파티에 메시지를 전송하기 위한 표준 형식입니다.이 경우, 상단의 코멘트가 수신자의 「커버 노트」가 됩니다.

보텀 포스트

"하단 게시" 스타일에서는 회신이 원본 메시지의 전체 또는 부분 사본에 추가됩니다.인라인 형식의 응답에 bottom-posting이라는 이름이 사용되는 경우가 있습니다.또한 1개의 포인트만 응답할 경우 2개의 형식은 동일합니다. 

수요일 오전 10시 1분에 Danny는 다음과 같이 썼습니다.> 수요일 오전 9시 40분에 Jim은 다음과 같이 썼습니다:>> 오늘 밤 5시부터 약 30분 동안 메일 서비스를 중단하고 몇 가지 업데이트 >> 및 중요한 수정을 설치합니다. 
 와!  잠깐만요.  5시 30분에 주요 기술 스탭에게 보고서를 메일로 발송하는 작업이 예정되어 있습니다.  한 시간만 뒤로 미룰 수 있을까요? 그런데 어떤 시스템이 갱신됩니까? 지난주 업데이트 후 네트워크 >에 문제가 발생했습니다.  재부팅해야 하나요?  문제 없습니다.그럼 오후 6시입니다. 
기본적으로는 WWW 서버와 방화벽을 업데이트합니다.아니요, 재부팅할 필요가 없습니다.

인라인 응답과 같이 하단 게시물은 포스터가 원본 메시지를 최대한 잘라서 독자들이 관련 없는 텍스트나 원본 메시지에서 이미 본 텍스트를 스크롤하지 않도록 합니다.

수요일 오전 10시 1분에 대니는 이렇게 썼다.> 1시간만 뒤로 미룰 수 있을까요? > [...] 갱신되는 시스템은 무엇입니까? [...] 재부팅해야 하나요?  문제 없습니다.그럼 오후 6시입니다.기본적으로는 WWW 서버와 방화벽을 업데이트합니다.아니요, 재부팅할 필요가 없습니다.

적절한 투고 스타일 선택

[필요한 건]

인터리브 게시, 상단 게시 및 하단 게시 중 선택은 일반적으로 포럼과 메시지의 특성에 따라 달라집니다.일부 포럼(개인 이메일 등)은 상당히 관대하며, 이 경우 적절한 스타일은 취향과 효과에 따라 결정됩니다.어느 경우든, 그 회신을 목적의 수신자가 쉽게 읽을 수 있을지를 검토할 필요가 있습니다.이메일 인터페이스에는 따옴표로 둘러싸인 라인 마커와 긴 라인을 처리하는 규칙이 다를 수 있습니다.따라서 화면에서 읽을 수 있는 것처럼 보이는 답변이 혼동되어 잘못된 색상으로 표시될 수 있습니다.빈 줄과 원문의 적절한 트리밍은 애매함을 피하는 데 도움이 될 수 있습니다.

인터리브 응답 스타일은 라벨링 행에 관한 작업이 더 필요할 수 있지만 각 응답 행의 컨텍스트를 확립하는 작업은 더 적을 수 있습니다.또한 인용문과 그 회신을 논리적인 읽기 순서로 가깝게 유지하고 인용된 자료를 최소한으로 자르도록 권장한다.이 스타일은 독자가 회신되는 원본 메시지의 포인트, 특히 응답이 원본 텍스트의 일부 포인트를 오해했는지 또는 무시했는지 여부를 쉽게 식별할 수 있도록 합니다.또한 인용된 부분을 임의의 순서로 배열할 수 있으며, 두 개 이상의 개별 메시지에서 인용된 인용문에 서로 포함하지 않더라도 단일 코멘트를 제공할 수 있습니다.

상단 및 하단 게시물은 응답이 단일 연속 텍스트라는 점에서 전통적인 서면 서신과 비교되기도 하며, 원문 전체가 회신되는 문자를 명확히 하기 위해서만 첨부된다.특히 고객 서비스 이메일 관행에서는 대부분의 경우 견적 없이 모든 사항을 명확하게 다루어야 하며, 원본 이메일 메시지는 첨부 파일로 포함될 수 있습니다.새로운 통신원이 진행 중인 [11][12]토론에 포함될 때도 원본 메시지 전체를 포함해야 할 수 있습니다.특히 비즈니스 서신에서는 메시지 스레드 전체를 제삼자에게 전송하여 처리 또는 논의를 해야 할 수 있습니다.한편, 새로운 독자(뉴스 그룹이나 온라인 포럼 등)가 전체 토론에 접근할 수 있는 환경에서는 이전 메시지를 완전히 포함하는 것이 적절하지 않습니다.따라서 인용이 필요한 경우 인터리브 스타일이 가장 좋습니다.

원본 메시지를 모두 인용할 경우, 어떤 이유로든 하단 포스트가 가장 적절한 형식입니다. 왜냐하면 하단 포스트는 응답의 논리적 순서를 유지하고 위에서 아래로 서양의 읽기 방향과 일관되기 때문입니다.

'네티켓 가이드라인(RFC 1855)'에서 인용한 '톱포스팅 대 보텀포스팅'에 대한 토론에서 흔히 볼 수 있다.위원회 프로세스를 통해 많은 RFC가 검토 및 승인되지만 RFC 1855와 같은 일부 RFC는 단순한 정보일 뿐 실제로는 개인적인 의견일 수도 있습니다.('정보' RFC에 대한 추가 정보는 RFC 2026의 '4.2.2 정보' 및 '4.2.3 절차 및 실험적 정보'에 있습니다.RFC 1855의 성질은 다음 내용을 읽을 때 고려해야 합니다.

RFC 1855에 따르면 메시지는 생략 요약으로 시작할 수 있습니다.즉, 투고는 선택적으로 인용하는 대신 다른 말로 시작할 수 있습니다.구체적으로는 다음과 같습니다.

메시지 또는 게시물에 회신할 경우 메시지 상단에 원본을 요약하거나 컨텍스트를 제공할 수 있을 만큼 원문의 텍스트만 포함해야 합니다.이것은 독자들이 당신의 답변을 읽기 시작할 때 확실히 이해할 수 있게 해줄 것입니다.특히 NetNews는 한 호스트에서 다른 호스트로 게시물을 배포함으로써 확산되기 때문에 원본 보기 전에 메시지에 대한 응답을 볼 수 있습니다.문맥을 알려주는 것은 모두에게 도움이 된다.하지만 원본 전체를 포함하지는 마세요!

인터리브 회신과 탑 포스트를 조합하여 두 스타일의 장점을 결합합니다.그러나 이것은 또한 원본 메시지의 일부분이 두 번 인용되는 결과를 초래하며, 이는 여분의 공간을 차지하여 독자를 혼란스럽게 할 수 있습니다.

전송에서는 원래 메시지 전체(모든 헤더 포함)를 MIME 첨부 파일로 포함하는 것이 바람직할 수 있습니다.또, 상단의 투고 응답에서는, 이러한 메시지 전체를 잘라내거나, 속성 행으로 치환하는 경우가 많습니다.따옴표로 묶이지 않은 메시지는 메타 정보의 주요 부분이 파괴되기 때문에 더 약한 형식의 문자입니다.(그 때문에, ISP의 Postmaster는, 통상은, 문제가 있는 E-메일의 전송 카피를 견적이 아니고 고집합니다).회송된 메시지는 일부 메일 클라이언트에서 상단 게시와 동일한 방식으로 표시됩니다.탑 포스트는 메일링 리스트 다이제스트에 심각한 파괴적인 것으로 간주됩니다.다양한 레벨의 탑 포스트는 건너뛰기 어렵습니다.최악의 경우는 원본 메시지로 다이제스트 전체를 포함하면서 탑 포스트하는 것입니다.

어떤 사람들은 "톱 포스트"가 대인관계 이메일에 적합하다고 생각하지만, 인라인 포스트는 뉴스 그룹 같은 스레드화된 토론에 항상 적용되어야 한다.

이 예는 메일링 리스트에서 상위 [13][14][15]투고를 조롱하거나 저지하기 위해 사용되는 경우가 있습니다.

왜냐하면 사람들이 보통 텍스트를 읽는 순서를 어지럽히기 때문이다.왜 탑포스팅이 그렇게 나쁜 일일까요?톱 포스트이메일에서 가장 짜증나는 것은 무엇입니까?

하단 게시물은 응답의 논리적 순서를 유지하며 위에서 아래로 서양의 읽기 방향과 일치합니다.

보텀 포스트에 반대하는 주된 이유는 답장을 찾기 위해 게시물을 아래로 스크롤하는 것이 불편하다는 것입니다.특히 긴 메시지에 대한 짧은 회신에서는 경험이 없는 컴퓨터 사용자가 쿼리에 대한 응답을 찾기 위해 아래로 스크롤해야 한다는 것을 모를 수 있습니다.맨 아래 게시된 메시지를 보낼 때 맨 위에 "I have replyed below"와 같은 알림과 함께 인라인 응답을 나타낼 수 있습니다.다만, 현대의 메일 프로그램의 상당수는, 다른 색상으로 다른 레벨의 견적을 표시할 수 있기 때문에(이 페이지의 하단의 투고 예에 나타나 있듯이), 이것은 그다지 문제가 되지 않습니다.응답 텍스트가 아직 남아 있음을 나타내는 또 다른 방법은 항상 서명 행으로 텍스트를 끝내는 것입니다.그러면 사용자의 응답 스타일에 익숙한 독서자는 서명 줄이 나타날 때까지 계속 읽어야 합니다.이 방법은 서명 행이 표시된 시점에서 응답이 완료되었음을 독자에게 알려주기 때문에 인라인 응답 방식을 사용할 때 특히 정중하고 유용합니다.

인기 메일 클라이언트 지원 견적

비즈니스 커뮤니케이션에 있어서의 이러한 광범위한 방침에 의해, 대부분의 유저에게 있어서, 하부 투고와 인라인 투고는 매우 불명확하게 되어, 가장 인기 있는 전자 메일 프로그램의 일부는 종래의 투고 스타일을 서포트하고 있지 않게 되었습니다.예를 들어 Microsoft Outlook, AOL 및 Yahoo!에서는 메시지의 어느 부분이 인용된 원본인지 나타내는 것이 어렵거나 불가능하거나 사용자가 원본의 일부 사이에 주석을 삽입할 수 없습니다.

Yahoo!에는 Mail Classic에서 "원래 메시지의 텍스트 인용" 옵션이 없지만, 이 설정은 새 메일에서 설정한 후 Mail Classic으로 다시 전환한 후에도 유지됩니다.Microsoft Outlook 에서는, 인라인 회신이 끊어집니다.원고의 각 행에 「보다 큰」문자(>)를 붙이는 설정을 선택해도, HTML E-메일의 따옴표 사이에 삽입된 회답은, 원고의 일부인 것처럼 보이게 되는 파란색 행이 생성됩니다.해결 방법은 "일반 텍스트로 모든 표준 메일 읽기" 설정을 사용하거나 원본 전자 메일의 "메시지 편집" 옵션을 사용하여 회신하기 전에 일반 텍스트로 변환하는 것입니다.[16]

레퍼런스

  1. ^ R. Gellens (2004년 2월), RFC 3676 텍스트/보편 형식 및 DelSp 파라미터
  2. ^ a b c S. Hambridge(1995년 10월), 네트워크 워킹 그룹 RFC 1855 NetApp 가이드라인
  3. ^ WWW(1993년)가 시작되기 전에 Google Groups의 Usenet 게시물 아카이브.
  4. ^ 급속히 증가하는 나의 이메일 습관 2007년 1월 19일 Wayback Machine 블로그 투고에서 아카이브
  5. ^ 2007년 9월 28일, Wayback Machine의 SirCam 아카이브 중지 - postfix.org 메일링 리스트
  6. ^ Top Posting and Mobiles: Jabber 메일링 리스트
  7. ^ "reply intelligently to e-mail". TechRepublic. 2006-01-19. Archived from the original (blog post and responses) on 2008-03-08. Retrieved 2013-04-12.
  8. ^ "Top posting" (Mailing list thread). FreeBSD mailing list. 2004-03-19. Retrieved 2007-01-11.
  9. ^ "Top-posting is so Microsoftish". SuSE Linux English discussion. 2002-10-13. Archived from the original (Mailing list thread) on 2004-12-24. Retrieved 2007-01-11.
  10. ^ Kennedy, Angus J.; Peter Buckley; Duncan Clark (October 2003). Andrew Dickson (ed.). The Rough Guide to the Internet 9 (Google Book Search) (2004 ed.). London: Penguin Books. p. 241. ISBN 1-84353-101-1. Retrieved 2007-01-11. It used to be taboo to reply at the top of a message ("top posting") until Microsoft made it the default setting
  11. ^ 견적: 톱 투고 - Dan's Mail Format 사이트
  12. ^ 2006년 10월 17일 Wayback Machine에서 아카이브된 현명한 이메일 - 블로그 투고 및 토론
  13. ^ "ARM Linux - Mailing Lists - Etiquette". linux.org.uk.
  14. ^ "Top Posting and Bottom Posting". idallen.com.
  15. ^ "What is Top Posting?". what-is-what.com.
  16. ^ "Making Outlook 2007 quote responsibly". loftninjas.org.

외부 링크