From bryce@scalum.com Fri Feb 1 00:04:09 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1D0F63A6868;
Fri, 1 Feb 2008 00:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 97.888
X-Spam-Level: ****************************************************************
X-Spam-Status: Yes, score=97.888 tagged_above=-999 required=5
tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451,
HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=1, INVALID_DATE=1.245,
RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5,
RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905,
RDNS_NONE=0.1, TRACKER_ID=2.003, URIBL_BLACK=20, URIBL_JP_SURBL=10,
URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20,
URIBL_SC_SURBL=10, URIBL_WS_SURBL=10]
X-Spam-Report:
* 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
* [score: 1.0000]
* 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private)
* 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS
* 1.2 INVALID_DATE Invalid Date: header (not RFC 2822)
* 2.0 TRACKER_ID BODY: Incorporates a tracking ID number
* 1.0 HTML_MESSAGE BODY: HTML included in message
* 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
* above 50%
* [cf: 100]
* 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
* 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level
* above 50%
* [cf: 100]
* 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
* [cf: 100]
* 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist
* [URIs: toptenwest.com]
* 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
* [URIs: toptenwest.com]
* 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
* [URIs: toptenwest.com]
* 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist
* [URIs: toptenwest.com]
* 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
* [URIs: toptenwest.com]
* 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
* [URIs: toptenwest.com]
* 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
* [123.22.81.94 listed in zen.spamhaus.org]
* 1.5 DNS_FROM_RFC_BOGUSMX RBL: Envelope sender in
* bogusmx.rfc-ignorant.org
* 20 URIBL_SBL Contains an URL listed in the SBL blocklist
* [URIs: toptenwest.com]
* 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS
Received: from core3.amsl.com ([127.0.0.1])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id wlksOL+N9B7s; Fri, 1 Feb 2008 00:04:08 -0800 (PST)
Received: from [123.22.81.94] (unknown [123.22.81.94])
by core3.amsl.com (Postfix) with ESMTP id 68D4B3A685C;
Fri, 1 Feb 2008 00:04:07 -0800 (PST)
Received: from [123.22.81.94] by smtp.secureserver.net; Fri, 32 Jan 2008 15:31:42 +0700
Date: Fri, 32 Jan 2008 15:31:42 +0700
From: "Janell Ware"
X-Mailer: The Bat! (v3.62.14) Educational
Reply-To: bryce@scalum.com
X-Priority: 3 (Normal)
Message-ID: <604744558.03921456012092@scalum.com>
To: discuss-archive@ietf.org
Subject: ***SPAM*** 97.888 (5) TakeALookWorldwideShippingProducts
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----------D3DA0C597BF6E8"
------------D3DA0C597BF6E8
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
New generation extra-strength med, for the treatment of ED only in men.
Benefits:
6-8 Hour Response Period;
Improves Focus;
Accelerates Recovery from Prior I|\|tercourse;
Amplified Passion and Desire;
Rapid-Absorption of the Chemical Component;
Increased Staaamina and Libido;
Psychological Confidence and Relief;
Helpfull in Hard Cases.
If you experience some lapses in your sexual life, please, do not hesitate or make your life worse.
Just a blue-pill will cure all your doubts and restore the life you will not help enjoying.
http://toptenwest.com
(Wait a moment until the page will be loaded entirely)
------------D3DA0C597BF6E8
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
New generation extra-strength med, for the treatment of ED only in men.
Benefits:
6-8 Hour Response Period;
Improves Focus;
Accelerates Recovery from Prior I|\|tercourse;
Amplified Passion and Desire;
Rapid-Absorption of the Chemical Component;
Increased Staaaamina and Libido;
Psychological Confidence and Relief;
Helpfull in Hard Cases.
If you experience some lapses in your sexual life, please, do not hesitate or make your life worse.
Just a blue-pill will cure all your doubts and restore the life you will not help enjoying.
http://toptenwest.com
(Wait a moment until the page will be loaded entirely)
------------D3DA0C597BF6E8--
From mailman-bounces@core3.amsl.com Fri Feb 1 05:53:11 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id BC7AF294D3A
for ; Fri, 1 Feb 2008 05:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,
BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id PpYPGqWZ3ZkV
for ;
Fri, 1 Feb 2008 05:52:42 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E6072294CFF
for ; Fri, 1 Feb 2008 05:28:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@ietf.org
To: discuss-archive@megatron.ietf.org
X-No-Archive: yes
Message-ID:
Date: Fri, 01 Feb 2008 05:04:36 -0800
Precedence: bulk
X-BeenThere: mailman@core3.amsl.com
X-Mailman-Version: 2.1.9
List-Id:
X-List-Administrivia: yes
Sender: mailman-bounces@core3.amsl.com
Errors-To: mailman-bounces@core3.amsl.com
This is a reminder, sent out once a month, about your ietf.org mailing
list memberships. It includes your subscription info and how to use
it to change it or unsubscribe from a list.
You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.
In addition to the URL interfaces, you can also use email to make such
changes. For more info, send a message to the '-request' address of
the list (for example, mailman-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.
If you have questions, problems, comments, etc, send them to
mailman-owner@ietf.org. Thanks!
http://www.ietf.org/mailman/options/discuss/discuss-archive%40megatron.ietf.org
From mailman-bounces@core3.amsl.com Fri Feb 1 05:55:43 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4809929477C
for ; Fri, 1 Feb 2008 05:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,
BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id h915L-1TSxtx
for ;
Fri, 1 Feb 2008 05:52:42 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6722E294D41
for ; Fri, 1 Feb 2008 05:28:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@ietf.org
To: discuss-archive@megatron.ietf.org
X-No-Archive: yes
Message-ID:
Date: Fri, 01 Feb 2008 05:04:37 -0800
Precedence: bulk
X-BeenThere: mailman@core3.amsl.com
X-Mailman-Version: 2.1.9
List-Id:
X-List-Administrivia: yes
Sender: mailman-bounces@core3.amsl.com
Errors-To: mailman-bounces@core3.amsl.com
This is a reminder, sent out once a month, about your ietf.org mailing
list memberships. It includes your subscription info and how to use
it to change it or unsubscribe from a list.
You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.
In addition to the URL interfaces, you can also use email to make such
changes. For more info, send a message to the '-request' address of
the list (for example, mailman-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.
If you have questions, problems, comments, etc, send them to
mailman-owner@ietf.org. Thanks!
http://www.ietf.org/mailman/options/discuss/discuss-archive%40megatron.ietf.org
From Byron.Bradford@moffettproperties.com Fri Feb 1 12:15:30 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B2A153A68F4
for ; Fri, 1 Feb 2008 12:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 79.419
X-Spam-Level: ****************************************************************
X-Spam-Status: Yes, score=79.419 tagged_above=-999 required=5
tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765,
FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_MISMATCH_NET=0.311,
INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5,
RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5,
RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905,
RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10,
URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10,
URIBL_WS_SURBL=10]
X-Spam-Report:
* 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
* [score: 1.0000]
* 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d
* 0.6 HELO_EQ_IT HELO_EQ_IT
* 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d
* 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE
* 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
* above 50%
* [cf: 100]
* 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
* 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
* [cf: 100]
* 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist
* [URIs: thestasist.com]
* 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
* [URIs: thestasist.com]
* 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
* [URIs: thestasist.com]
* 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
* [URIs: thestasist.com]
* 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist
* [URIs: thestasist.com]
* 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
* [URIs: thestasist.com]
* 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
* [Blocked - see ]
* 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
* [81.208.83.230 listed in zen.spamhaus.org]
* 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
* 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org
* []
* 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
* [81.208.83.230 listed in dnsbl.sorbs.net]
* 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822
* 0.1 RDNS_DYNAMIC Delivered to trusted network by host with
* dynamic-looking rDNS
* 0.3 HOST_MISMATCH_NET HOST_MISMATCH_NET
Received: from core3.amsl.com ([127.0.0.1])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id lxfZU0DqG9Zc
for ;
Fri, 1 Feb 2008 12:15:29 -0800 (PST)
Received: from giannib1a52108.fastwebnet.it (81-208-83-230.fastres.net [81.208.83.230])
by core3.amsl.com (Postfix) with SMTP id 8527628C276
for ; Fri, 1 Feb 2008 12:14:43 -0800 (PST)
Date: Fri, 1 Feb 2008 21:12:26 -0100
Message-ID: 248e01c8650f$4a1516b0$3a2c1617@giannib1a52108
From: "Doctor Byron Bradford"
To:
Subject: ***SPAM*** 79.419 (5) Something interesting for you
MIME-Version: 1.0
X-Priority: 3 (Normal)
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
Do you want to forget about your sexual problems?
You dont know what to do? It's simply!
For more details click here
http://thestasist.com/
Best regards and have a passionate love
From nina.cerkovnik@ade.com Tue Feb 5 10:38:14 2008
Return-Path:
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id E950D3A6BEC; Tue, 5 Feb 2008 10:52:55 -0800 (PST)
Received: from 151.205.197-77.rev.gaoland.net (unknown [77.197.205.151])
by mail.ietf.org (Postfix) with SMTP id 3E21E3A6F92
for ; Mon, 4 Feb 2008 14:22:06 -0800 (PST)
Received: from [38.131.86.51] (helo=ltjz)
by 151.205.197-77.rev.gaoland.net with smtp (Exim 4.62 (FreeBSD))
id 1JMAfz-0007KJ-2O; Mon, 4 Feb 2008 23:26:43 +0100
Message-ID: <47A7906C.4020701@ade.com>
Date: Mon, 4 Feb 2008 23:23:40 +0100
From:
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: discuss-archive@ietf.org
Subject: Brand-trusted blue-pill!
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 080204-0, 04/02/2008), Outbound message
X-Antivirus-Status: Clean
Can u believe that WE will make you h@ppy? http://vjjm.speakpound.com
From _upro_3ix_mail@mcelectric.com Tue Feb 5 10:38:54 2008
Return-Path: <_upro_3ix_mail@mcelectric.com>
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id 7B4173A8D1E; Tue, 5 Feb 2008 10:52:54 -0800 (PST)
Received: from 215.subnet125-161-2.speedy.telkom.net.id (unknown [125.161.2.215])
by mail.ietf.org (Postfix) with SMTP id 1D42A3A8C93
for ; Mon, 4 Feb 2008 23:30:27 -0800 (PST)
Received: from uqeu ([113.38.214.118]) by 215.subnet125-161-2.speedy.telkom.net.id with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Feb 2008 14:31:52 +0700
Message-ID: <000e01c867c9$2d109cd0$76d62671@uqeu>
From: <_upro_3ix_mail@mcelectric.com>
To:
Subject: I Love You with All I Am
Date: Tue, 5 Feb 2008 14:31:52 +0700
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437
Our Love is Free http://121.158.6.109/
From rhvillagran@bss.ind.in Tue Feb 5 10:43:12 2008
Return-Path:
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id AC30C3A6B02; Tue, 5 Feb 2008 10:52:50 -0800 (PST)
Received: from host172-32-dynamic.2-79-r.retail.telecomitalia.it (host172-32-dynamic.2-79-r.retail.telecomitalia.it [79.2.32.172])
by mail.ietf.org (Postfix) with SMTP id 6049B3A99BB
for ; Tue, 5 Feb 2008 03:15:48 -0800 (PST)
Received: from veod ([209.212.188.112])
by host172-32-dynamic.2-79-r.retail.telecomitalia.it (8.13.5/8.13.5) with SMTP id m15BKhZl053336;
Tue, 5 Feb 2008 12:20:43 +0100
Message-ID: <47A845F6.4020508@bss.ind.in>
Date: Tue, 5 Feb 2008 12:18:14 +0100
From:
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: discuss-archive@ietf.org
Subject: U can be sure in success with this time-tested blue bill
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 071208-0, 08/12/2007), Outbound message
X-Antivirus-Status: Clean
Make her tremble with passion! http://fgai.measureremember.com
From Contact@clientbydesign.us Tue Feb 5 10:43:36 2008
Return-Path:
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id 359D53A71C8; Tue, 5 Feb 2008 10:52:53 -0800 (PST)
Received: from cpe-075-183-097-107.triad.res.rr.com (cpe-075-183-097-107.triad.res.rr.com [75.183.97.107])
by mail.ietf.org (Postfix) with SMTP id 9BD373A8104
for ; Mon, 4 Feb 2008 19:30:47 -0800 (PST)
Message-ID: <7ff501c867a7$025a5f67$6b61b74b@cpe-075-183-097-107.triad.res.rr.com>
From: "Sales"
To: "discuss-archive@ietf.org"
Subject: Up to 50% Off Clearance Products
Date: Tue, 05 Feb 2008 03:30:37 +0000
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----=_NextPart_000_C39E_3F0C8DAE.7C530AFB"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
This is a multi-part message in MIME format.
------=_NextPart_000_C39E_3F0C8DAE.7C530AFB
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_2C69_4A6C39E3.F0C8DAE7"
------=_NextPart_001_2C69_4A6C39E3.F0C8DAE7
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
The development of the printing press, however, presented printers with =
dilemmas: texts from the fifteenth through to the seventeenth centuries =
show many internal inconsistencies, with the same word often being spelled =
differently within the same text. Famously, Shakespeare spelled his own =
name in many different ways. Additionally, they were tempted to choose from=20
the various spellings based on typographical criterion, e.g. to get =
uniform line lengths when assembling type pieces on a composing stick. It =
being easier to make one of the lines of type longer than to make the other=20
lines shorter, word lengths tended to standardize on the longer spellings.
=20
Starting from NOW you can order =20
Original Viagra and other Genuine Products!=20
Other semantic change includes narrowing and broadening. Narrowing a word =
semantically limits its alternative meanings. For example the word 'girl' =
once meant 'a young child' and 'hound' (spelt 'hund') meant 'all canines', =
and now of course it means a particular type. Examples of words that have =
been broadened semantically include 'dog' (which once meant a particular =
breed).
=20
Get it here: http://www.cabaretsandclubs.info=20
=20
The closest one might come to CS in an interview is when the subject is =
interrupted by a close friend or family member, or perhaps must answer the =
phone. CS is used in a completely unmonitored environment where the subject=20
feels most comfortable and will use their natural vernacular without =
overtly thinking about it.
=20
Prices Are TAX Free - Worldwide Shipping - Prices are VAT Free
------=_NextPart_001_2C69_4A6C39E3.F0C8DAE7
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Modern historical linguistics dates from the late 18th century and=20
grew out of the earlier discipline of philology, the study of ancient =
texts and documents, which goes back to antiquity.
Starting from NOW you can =
order =20
Original =
Viagra and other Genuine Products!=20
The sociolinguist =
William Labov famously recorded the change in pronunciation in a relatively=20
short period in the American resort of Martha=92s Vineyard and showed how =
this was the result of social tensions and processes.[1] Even in the =
relatively short time that broadcast media have been available, we can =
observe the difference between the =91marked=92 pronunciation of the =
newsreaders of the 1940s and the 1950s and the more neutral, =91unmarked=92=20
pronunciation of today. The greater acceptance and fashionability of =
regional accents in the media may also reflect a more democratic, less =
formal society.
The development of the printing press, however, presented =
printers with dilemmas: texts from the fifteenth through to the seventeenth=20
centuries show many internal inconsistencies, with the same word often =
being spelled differently within the same text. Famously, Shakespeare =
spelled his own name in many different ways. Additionally, they were =
tempted to choose from the various spellings based on typographical =
criterion, e.g. to get uniform line lengths when assembling type pieces on =
a composing stick. It being easier to make one of the lines of type longer =
than to make the other lines shorter, word lengths tended to standardize on=20
the longer spellings.
Prices Are TAX Free - =
Worldwide Shipping - Prices are VAT =
Free
------=_NextPart_001_2C69_4A6C39E3.F0C8DAE7--
------=_NextPart_000_C39E_3F0C8DAE.7C530AFB
Content-Type: image/jpeg;
name="=?iso-8859-1?B?E3F0C8DAE7C530AFB2C6=?="
Content-Transfer-Encoding: base64
Content-ID:
/9j/4AAQSkZJRgABAgEASABIAAD/7QSqUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA
SAAAAAAC2gIo/+H/4QL5AkUDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB
Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4
QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA
AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA
L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN
A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD/////////////////////////
////A+gAAAAA/////////////////////////////wPoAAAAAP//////////////////////////
//8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC
QAAAAAA4QklNBAkAAAAAApkAAAABAAAAgAAAAAEAAAGAAAABgAAAAn0AGAAB/9j/4AAQSkZJRgAB
AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i
ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAEAgAMBIgACEQEDEQH/3QAEAAj/xAE/
AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK
CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS
U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam
tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx
QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV
xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APTqPon4/wAAir5X
SQGyn6oSXyukip+qEl8rpJKfqhJfK6SSn6oSXyukkp+qEl8rpJKfqhJfK6SSn6oSXyukkp//2QA4
QklNBAYAAAAAAAcABAAAAAEBAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0
LjAA/+4ADkFkb2JlAGQAAAAAAf/bAIQABgQEBwUHCwYGCw4KCAoOEQ4ODg4RFhMTExMTFhEMDAwM
DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEHCQkTDBMiExMiFA4ODhQUDg4ODhQRDAwM
DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAAwZAAwERAAIRAQMR
Af/dAAQAyP/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA
AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB
UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE
1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ
qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy
obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp
0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo
+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A9N/vv+Lv+SWFhv5/7F37
7/i7/kliu/n/ALFbJ63H/dv0+lTFd/P/AGKj++/y/wDkliu/n/sVa29Tl8fSn7fCn/JPfFIRH/AY
GTv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi
rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w
GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3
/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd
/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFX
f8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gM
Vd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+
AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8A
gMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/
4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq
7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wAB
irv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi
rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w
GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3
/AYq/wD/2Q==
------=_NextPart_000_C39E_3F0C8DAE.7C530AFB--
From elaine9@my-deja.com Tue Feb 5 10:45:42 2008
Return-Path:
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id 175103A6D4A; Tue, 5 Feb 2008 10:36:44 -0800 (PST)
Received: from 5ac510d1.bb.sky.com (5ac510d1.bb.sky.com [90.197.16.209])
by mail.ietf.org (Postfix) with ESMTP id 5C30828DA41
for ; Tue, 5 Feb 2008 10:08:48 -0800 (PST)
Message-ID: <000601c86822$04cb058f$fb2d44ad@akvcawl>
From: "lennard hesperos"
To:
Subject: Cialiis Email from ED.
Date: Tue, 05 Feb 2008 16:22:53 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0003_01C86822.04C6F4A3"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
This is a multi-part message in MIME format.
------=_NextPart_000_0003_01C86822.04C6F4A3
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
headache; indigestion; back pain; muscle aches; flushing; stuffy or =
runny nose; or temporary blue tint in vision or difficulty telling the =
difference between the colors blue and green (uncommon).
FDA has approved new labels for C1alis Ind1an cheeap meedss
------=_NextPart_000_0003_01C86822.04C6F4A3
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
headache; indigestion; back pain; muscle aches; flushing; stuffy or =
runny nose; or temporary blue tint in vision or difficulty telling the =
difference between the colors blue and green (uncommon).
FDA has approved =
new labels for C1alis Ind1an cheeap meedss
------=_NextPart_000_0003_01C86822.04C6F4A3--
From -updates@7-10.com Tue Feb 5 10:45:53 2008
Return-Path: <-updates@7-10.com>
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id 287913A771D; Tue, 5 Feb 2008 10:52:53 -0800 (PST)
Received: from host240-113-dynamic.16-87-r.retail.telecomitalia.it (host240-113-dynamic.16-87-r.retail.telecomitalia.it [87.16.113.240])
by mail.ietf.org (Postfix) with ESMTP id 92C6B3A7C2A
for ; Mon, 4 Feb 2008 18:11:52 -0800 (PST)
Message-ID: <000901c8679c$07c228c7$03645299@lqeucja>
From: "kelbee stamos" <-updates@7-10.com>
To:
Subject: Wide spectrum of boner enlargers!
Date: Tue, 05 Feb 2008 00:25:12 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0006_01C8679C.07BD1226"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
This is a multi-part message in MIME format.
------=_NextPart_000_0006_01C8679C.07BD1226
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Your girl can't keep her hands off you!
Order
------=_NextPart_000_0006_01C8679C.07BD1226
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Your girl can't keep her hands off you!
Order
------=_NextPart_000_0006_01C8679C.07BD1226--
From clydetroubling4982079@yahoo.com Tue Feb 5 11:00:03 2008
Return-Path:
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id 4F7A53A68B9; Tue, 5 Feb 2008 10:53:01 -0800 (PST)
Received: from host13-213-dynamic.15-87-r.retail.telecomitalia.it (host13-213-dynamic.15-87-r.retail.telecomitalia.it [87.15.213.13])
by mail.ietf.org (Postfix) with SMTP id A85D83AA28F;
Tue, 5 Feb 2008 05:01:28 -0800 (PST)
Received: from 102.126.240.168 by 87.15.213.13; Tue, 05 Feb 2008 07:59:54 -0500
Message-ID:
From: "Jed Varner"
Reply-To: "Jed Varner"
To: dhcwg-request@ietf.org
Subject: Repl1ca watch is a perfect gift!
Date: Tue, 05 Feb 2008 08:03:54 -0500
MIME-Version: 1.0
X-Antivirus: avast! (VPS 080131-1, 31/01/2008), Outbound message
X-Antivirus-Status: Clean
Newest 2008 repl1ca watch3s collection!
15% off in February and huge choose of repl1cas!
http://www.oisoiske.com/
From somun@lanier.com Tue Feb 5 11:00:51 2008
Return-Path:
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id CACD53A6F94; Tue, 5 Feb 2008 10:58:05 -0800 (PST)
Received: from cpe-76-183-124-128.tx.res.rr.com (cpe-76-183-124-128.tx.res.rr.com [76.183.124.128])
by mail.ietf.org (Postfix) with SMTP id B80F728DA2B
for ; Tue, 5 Feb 2008 10:07:25 -0800 (PST)
Received: from ulca ([88.148.93.214]) by cpe-76-183-124-128.tx.res.rr.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Feb 2008 12:08:57 -0600
Message-ID: <002001c86822$2cec7590$d65d9458@ulca>
From:
To:
Subject: A Is For Attitude
Date: Tue, 5 Feb 2008 12:08:57 -0600
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
The Dance of Love http://98.200.126.101/
From francisc89@ohiohills.com Tue Feb 5 11:01:25 2008
Return-Path:
X-Original-To: discuss-archive@ietf.org
Delivered-To: ietfarch-discuss-archive@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51)
id BF1D13A811B; Tue, 5 Feb 2008 10:37:55 -0800 (PST)
Received: from dsl.dynamic81213165236.ttnet.net.tr (unknown [81.213.165.236])
by mail.ietf.org (Postfix) with ESMTP id CE6023A9DD5
for ; Tue, 5 Feb 2008 04:06:00 -0800 (PST)
Message-ID: <000501c867ef$0680a154$ea41eb8e@aqnjaee>
From: "bord boaz"
To:
Subject: V|a_g r-a 100mg x 60 pills = $ 109.95
Date: Tue, 05 Feb 2008 10:20:13 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0002_01C867EF.067E3D3A"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
This is a multi-part message in MIME format.
------=_NextPart_000_0002_01C867EF.067E3D3A
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
If you develop dizziness, nausea, or angina (pain, tightness, =
discomfort, numbness, or tingling in the chest, arms, neck, or jaw) =
during sexual activity, refrain from further sexual activity and notify =
your doctor.Viagrra 50mg x 10 piills =3D $ 45.95 want cheap it, get =
cheap it from India!
------=_NextPart_000_0002_01C867EF.067E3D3A
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
If you develop dizziness, nausea, or angina (pain, tightness, =
discomfort, numbness, or tingling in the chest, arms, neck, or jaw) =
during sexual activity, refrain from further sexual activity and notify =
your doctor.
Viagrra 50mg x =
10 piills =3D $ 45.95 want cheap it, get cheap it from =
India!
------=_NextPart_000_0002_01C867EF.067E3D3A--
From discuss-bounces@ietf.org Thu Feb 7 11:53:04 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 34C843A7AD0;
Thu, 7 Feb 2008 11:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.624
X-Spam-Level:
X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5
tests=[AWL=-0.625, BAYES_50=0.001]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BREtAbHdxhgR; Thu, 7 Feb 2008 11:53:04 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 065DC3A69FA;
Thu, 7 Feb 2008 11:53:04 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0BAB33A7A6C
for ; Thu, 7 Feb 2008 11:53:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TOUZrm-ucrOK for ;
Thu, 7 Feb 2008 11:53:02 -0800 (PST)
Received: from mk-outboundfilter-2.mail.uk.tiscali.com
(mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38])
by core3.amsl.com (Postfix) with ESMTP id 0AD9E3A797C
for ; Thu, 7 Feb 2008 11:53:01 -0800 (PST)
X-Trace: 2619371/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.32
X-SBRS: None
X-RemoteIP: 62.241.162.32
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAFrxqkc+8aIg/2dsb2JhbACsOA
X-IP-Direction: IN
Received: from ranger.systems.pipex.net ([62.241.162.32])
by smtp.pipex.tiscali.co.uk with ESMTP; 07 Feb 2008 19:54:28 +0000
Received: from pc6 (1Cust202.tnt30.lnd3.gbr.da.uu.net [62.188.122.202])
by ranger.systems.pipex.net (Postfix) with SMTP id BC93CE00008C;
Thu, 7 Feb 2008 19:54:27 +0000 (GMT)
Message-ID: <00bd01c869ba$93689f80$0601a8c0@pc6>
From: "tom.petch"
To: "tom.petch" ,
References: <035301c867fc$c78a2c80$0601a8c0@pc6>
Subject: Re: Test
Date: Thu, 7 Feb 2008 19:35:47 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch"
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
In case you were wondering what I was on about, this mailing list is now
discuss@ietf.org
dropping the reference to apps (which confused me initially
Tom Petch
----- Original Message -----
From: "tom.petch"
To:
Sent: Tuesday, February 05, 2008 1:57 PM
Subject: Test
> Just trying to find where apps-discuss has gone to post-reorganisation.
>
> Tom Petch
>
From discuss-bounces@ietf.org Thu Feb 7 11:54:39 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id AA11F3A7AEC;
Thu, 7 Feb 2008 11:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.838
X-Spam-Level:
X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=0.200,
BAYES_00=-2.599, J_CHICKENPOX_35=0.6, NO_RDNS_DOTCOM_HELO=0.001,
RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id RafOtVoPXU5l; Thu, 7 Feb 2008 11:54:39 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 7A12A3A79B6;
Thu, 7 Feb 2008 11:54:39 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E051A3A797C;
Thu, 7 Feb 2008 11:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1qY6VuA+X0-l; Thu, 7 Feb 2008 11:54:37 -0800 (PST)
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
by core3.amsl.com (Postfix) with ESMTP id 21DD23A713F;
Thu, 7 Feb 2008 11:54:37 -0800 (PST)
Received: from naturevery-lm.corp.yahoo.com (unknown [207.126.230.225])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by smtp.mxes.net (Postfix) with ESMTP id 0089BD05A1;
Thu, 7 Feb 2008 14:56:04 -0500 (EST)
From: Mark Nottingham
To: "tom.petch"
In-Reply-To: <00bd01c869ba$93689f80$0601a8c0@pc6>
Subject: Re: Test
X-Priority: 3
References: <035301c867fc$c78a2c80$0601a8c0@pc6>
<00bd01c869ba$93689f80$0601a8c0@pc6>
Message-Id:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Thu, 7 Feb 2008 11:56:04 -0800
X-Mailer: Apple Mail (2.915)
Cc: discuss@ietf.org
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
That seems like a bug, not a feature..
BCC:ing ietf-action...
On 07/02/2008, at 10:35 AM, tom.petch wrote:
> In case you were wondering what I was on about, this mailing list is
> now
> discuss@ietf.org
> dropping the reference to apps (which confused me initially
>
> Tom Petch
>
> ----- Original Message -----
> From: "tom.petch"
> To:
> Sent: Tuesday, February 05, 2008 1:57 PM
> Subject: Test
>
>
>> Just trying to find where apps-discuss has gone to post-
>> reorganisation.
>>
>> Tom Petch
>>
--
Mark Nottingham http://www.mnot.net/
From discuss-bounces@ietf.org Thu Feb 7 12:57:34 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CAEB03A78C5;
Thu, 7 Feb 2008 12:57:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.033
X-Spam-Level:
X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-0.116,
BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 0j2D78FqZ0ZG; Thu, 7 Feb 2008 12:57:34 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 184123A7928;
Thu, 7 Feb 2008 12:57:29 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E184B3A6E2F
for ; Thu, 7 Feb 2008 12:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id OVgMTao4rF3s for ;
Thu, 7 Feb 2008 12:57:26 -0800 (PST)
Received: from outbound-mail-106.bluehost.com (outbound-mail-106.bluehost.com
[69.89.22.6]) by core3.amsl.com (Postfix) with SMTP id F23073A7140
for ; Thu, 7 Feb 2008 12:56:33 -0800 (PST)
Received: (qmail 17245 invoked by uid 0); 7 Feb 2008 20:58:04 -0000
Received: from unknown (HELO box7.bluehost.com) (69.89.30.147)
by xmail.bluehost.com with SMTP; 7 Feb 2008 20:58:04 -0000
Received: from [209.234.108.194] (helo=KingsMountain.com)
by box7.bluehost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68)
(envelope-from ) id 1JNDoo-0000MN-FQ
for discuss@ietf.org; Thu, 07 Feb 2008 13:58:02 -0700
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-7) with nmh-1.1
Subject: Re: Test
To: discuss@ietf.org
In-reply-to: Mark Nottingham 's message of
Thu, 07 Feb 2008 11:56:04 -0800
From: ' =JeffH '
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 07 Feb 2008 12:58:04 -0800
X-Identified-User: {32571:box7.bluehost.com:kingsmou:kingsmountain.com}
{sentby:bopbeforesmtp 209.234.108.194 authed with
kingsmountain.com}
Message-Id: <20080207205633.F23073A7140@core3.amsl.com>
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ' =JeffH '
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
Uh yeah, that's a bug -- the list is for general "applications area"
discussions.
=JeffH
From discuss-bounces@ietf.org Thu Feb 7 14:07:30 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A88203A7BBA;
Thu, 7 Feb 2008 14:07:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.354
X-Spam-Level:
X-Spam-Status: No, score=-4.354 tagged_above=-999 required=5
tests=[AWL=-1.356, BAYES_50=0.001, HTML_FONT_SIZE_LARGE=0.001,
HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9NAJZp4XJjlu; Thu, 7 Feb 2008 14:07:30 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6D32C3A7B78;
Thu, 7 Feb 2008 14:07:30 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 278AD3A79AA
for ; Thu, 7 Feb 2008 14:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QeG1CdvpDBKy for ;
Thu, 7 Feb 2008 14:07:27 -0800 (PST)
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org
[204.152.186.98])
by core3.amsl.com (Postfix) with ESMTP id CE7FE3A7BDD
for ; Thu, 7 Feb 2008 14:07:23 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
by laweleka.osafoundation.org (Postfix) with ESMTP id 1937D14274B
for ; Thu, 7 Feb 2008 14:08:57 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
port 10024) with ESMTP id a0Ram52W6T7H for ;
Thu, 7 Feb 2008 14:08:50 -0800 (PST)
Received: from [10.1.4.108] (ip20.commerce.net [157.22.41.20])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by laweleka.osafoundation.org (Postfix) with ESMTP id 3003B142746
for ; Thu, 7 Feb 2008 14:08:50 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
To: discuss@ietf.org
Message-Id: <0CB355F1-4A6A-4AAD-8623-94C0D4AF13FD@osafoundation.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-1-776628520
From: Lisa Dusseault
Subject: PP16: Applying Agile Programming Principles to IETF Protocol Design
Date: Thu, 7 Feb 2008 14:08:47 -0800
X-Mailer: Apple Mail (2.752.3)
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
--Apple-Mail-1-776628520
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=WINDOWS-1252;
delsp=yes;
format=flowed
For those attending AAAW next week: This brings the total to 16 =20
papers, with 3 days left. If you haven't read any yet, that's 5 =20
papers per day...
Lisa
Applying Agile Programming Principles to IETF Protocol Design
Tony Hansen
Back in the early days of the IETF, many of the protocols were =20
created from the ground up and the documents written afterwards. The =20
mantra =91running code=92 reigned. Many protocols were written this way =20=
and became full standards.
Over the years, this method of creating protocols made way to follow =20
more closely the waterfall model of software development: a proposal =20
would be made, requirements would be written, and subsequently a =20
design would be written. The protocol would sometimes wither and die =20
at this point, as implementations may or may not be written. =20
Sometimes the protocol would get implemented and be found wanting, =20
requiring revisions and recycling back to proposed standard. =20
Sometimes the protocol would actually make it, but rarely would a =20
protocol get revised in order to make it through to the full standard =20=
status.[1]
(Concomitant with this trend has been the increased participation in =20
the IETF by =93professional standards people=94 and the decreased =20
participation by engineers.)
In the software world, it=92s been found that there are many flaws in =20=
the waterfall model, and other models have been proposed that attempt =20=
to alleviate those flaws. In particular, some other models are =20
iterative development, incremental development, extreme programming =20
and agile programming. Proponents of the Extreme Programming =20
practices claim that =93exercising these practices=97traditional =
software =20
engineering practices taken to so-called =91extreme=92 levels=97leads to =
a =20
development process that is more responsive to customer needs =20
("agile") than traditional methods, while creating software of better =20=
quality.=94 [2]
Here=92s an overview of agile development methods from Wikipedia:[3]
There are many agile development methods; most minimize risk by =20
developing software in short amounts of time. Software developed =20
during one unit of time is referred to as an iteration, which may =20
last from one to four weeks. Each iteration is an entire software =20
project: including planning, requirements analysis, design, coding, =20
testing, and documentation. An iteration may not add enough =20
functionality to warrant releasing the product to market but the goal =20=
is to have an available release (without bugs) at the end of each =20
iteration. At the end of each iteration, the team re-evaluates =20
project priorities.
Notice the emphasis on quick iteration, with a complete set of =20
development steps occurring in each cycle. Also notice that each =20
cycle does not necessarily end in a finished product.
Is there a way that we could make use of similar principles in IETF =20
protocol development? And if so, what benefits can we possibly achieve?
What if a working group were to develop protocols in the following =20
order?
Work on requirements
Work on an area of the design
People implement the updated design
Test implementations in an interoperation event
At the end of each cycle, you then check for these things:
Were the implementations able to interoperate?
Does the protocol still satisfy the need?
Is the design complete? Are there any areas not completed yet?
This continues until everyone agrees that all of these criteria have =20
been satisfied.
During each iteration,
The purpose of the requirements work is to refine the requirements =20
from the previous iteration using the insights gained during the =20
previous implementation effort and interoperation event.
The purpose of the design work is to pick off another part of the =20
whole. You do not need to have everything perfect in all areas of the =20=
protocol, but instead can focus on a smaller piece of the protocol.
The purpose of the implementation step and interoperation event is to =20=
gain insights on those portions of the design that were worked on =20
during this cycle, as well as how well things work together.
The output of each cycle is an updated version of the requirements =20
document and the design document(s), that is, updated internet drafts.
Only when the exit criteria have been fully satisfied do the =20
documents get published as RFCs.
Notice that it is conceivable that an entire cycle can be =20
accomplished in the time between IETF meetings. The interoperation =20
events could potentially occur during the IETF meeting week.
Note also that
There is a renewed focus on running code.
At the end of the cycles, in addition to the protocol description, =20
you have multiple interoperable implementations.
It is conceivable that protocols developed in this fashion could be =20
considered to be Full Standards right out of the box.
The key to making this work within a cycle is focusing on only a =20
portion of the design each time and not trying to solve the world=92s =20=
problems each time; focusing in on a smaller piece of the puzzle.
A BOF is still useful for determining if there is interest in working =20=
on a proposed protocol, and as a way to encourage initial =20
requirements and designs for it. They would prime the pump for the =20
working group cycles.
The style of managing a working group would need to be more directed =20
towards forcing a workable set of code at the end of each iteration. =20
It also requires a thought process that allows certain parts of a =20
protocol to be left unfinished while working on other portions of the =20=
protocol. This requires a somewhat different set of skills than is =20
commonly found in current working group chairs. It also requires the =20
working group to be in agreement to use this methodology.
This methodology is oriented toward
Brand new protocols
Discrete extensions to existing protocols[4]
This methodology is not oriented toward small increments to existing =20
protocols.
Summary: I propose running a process experiment.
[1] A case in point is the Message Tracking protocol. It had lots of =20
support during the requirements and design phases, but when it came =20
to being implemented after it was published, forget it.
[2] http://en.wikipedia.org/wiki/Extreme_Programming
[3] http://en.wikipedia.org/wiki/Agile_software_development
[4] For example, many of the proposed IMAP extensions are of this =20
nature.=
--Apple-Mail-1-776628520
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=WINDOWS-1252
For those attending AAAW =
next week: This brings the total to 16 papers, with 3 days left.=A0 If =
you haven't read any yet, that's 5 papers per day...=A0
Lisa
Applying =
Agile Programming Principles to IETF Protocol =
Design
Tony Hansen
Back in the early days of =
the IETF, many of the protocols were created from the ground up and the =
documents written afterwards. The mantra =91running code=92 reigned. =
Many protocols were written this way and became full standards.
Over the years, this =
method of creating protocols made way to follow more closely the =
waterfall model of software development: a proposal would be made, =
requirements would be written, and subsequently a design would be =
written. The protocol would sometimes wither and die at this point, as =
implementations may or may not be written. Sometimes the protocol would =
get implemented and be found wanting, requiring revisions and recycling =
back to proposed standard. Sometimes the protocol would actually make =
it, but rarely would a protocol get revised in order to make it through =
to the full standard status.
(Concomitant with this =
trend has been the increased participation in the IETF by =93professional =
standards people=94 and the decreased participation by engineers.)
In the software world, =
it=92s been found that there are many flaws in the waterfall model, and =
other models have been proposed that attempt to alleviate those flaws. =
In particular, some other models are iterative development, incremental =
development, extreme programming and agile programming.=A0 Proponents of the Extreme =
Programming =A0practices claim =
that =93exercising these practices=97traditional software engineering =
practices taken to so-called =91extreme=92 levels=97leads to a =
development process that is more responsive to customer needs ("agile") =
than traditional methods, while creating software of better quality.=94 =
Here=92s an overview of =
agile development methods from Wikipedia:
There are many agile =
development methods; most minimize risk by developing software in short =
amounts of time. Software developed during one unit of time is referred =
to as an iteration, which may last from one to four weeks. Each =
iteration is an entire software project: including planning, =
requirements analysis, design, coding, testing, and documentation. An =
iteration may not add enough functionality to warrant releasing the =
product to market but the goal is to have an available release (without =
bugs) at the end of each iteration. At the end of each iteration, the =
team re-evaluates project priorities.
Notice the emphasis on quick iteration, with =
a complete set of development steps occurring in each cycle. Also notice =
that each cycle does not necessarily end in a =
finished product.
Is there a way that we could make use of =
similar principles in IETF protocol development? And if so, what =
benefits can we possibly achieve?
What if a working group were to develop =
protocols in the following order?
- Work on requirements
- Work on an area of the design
- People implement the updated design
- Test implementations in an interoperation event
At the end of each =
cycle, you then check for these things:
- Were the implementations able to interoperate?
- Does the protocol still satisfy the =
need?
- Is the design complete? Are there =
any areas not completed yet?
This continues until everyone agrees that =
all of these criteria have been satisfied.
During each iteration,
- The purpose of the requirements work is to refine the =
requirements from the previous iteration using the insights gained =
during the previous implementation effort and interoperation =
event.
- The purpose of the design work is =
to pick off another part of the whole. You do not need to have everything perfect in all areas of the =
protocol, but instead can focus on a smaller piece of the =
protocol.
- The purpose of the implementation step and interoperation =
event is to gain insights on those portions of the design that were =
worked on during this cycle, as well as how well things work =
together.
The =
output of each cycle is an updated version of the requirements document =
and the design document(s), that is, updated internet drafts.
Only when the exit =
criteria have been fully satisfied do the documents get published as =
RFCs.
Notice that =
it is conceivable that an entire cycle can be accomplished in the time =
between IETF meetings. The interoperation events could potentially occur =
during the IETF meeting week.
Note also that
- There is a renewed focus on running code.
- At the end of the cycles, in addition to the =
protocol description, you have multiple interoperable =
implementations.
- It is conceivable that protocols developed in this fashion =
could be considered to be Full Standards right out of the =
box.
The key =
to making this work within a cycle is focusing on only a portion of the =
design each time and not trying to solve the world=92s problems each =
time; focusing in on a smaller piece of the puzzle.
A BOF is still useful =
for determining if there is interest in working on a proposed protocol, =
and as a way to encourage initial requirements and designs for it. They =
would prime the pump for the working group cycles.
The style of managing a =
working group would need to be more directed towards forcing a workable =
set of code at the end of each iteration. It also requires a thought =
process that allows certain parts of a protocol to be left unfinished =
while working on other portions of the protocol. This requires a =
somewhat different set of skills than is commonly found in current =
working group chairs. It also requires the working group to be in =
agreement to use this methodology.
This methodology is oriented toward
- Brand new protocols
- Discrete extensions to existing protocols
This methodology is =
not oriented toward small increments to existing =
protocols.
Summary: I propose running a process =
experiment.
A case in =
point is the Message Tracking protocol. It had lots of support during =
the requirements and design phases, but when it came to being =
implemented after it was published, forget =
it. <=
DIV style=3D"mso-element:footnote" id=3D"ftn4">
=
--Apple-Mail-1-776628520--
From discuss-bounces@ietf.org Thu Feb 7 23:22:46 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 041003A80C3;
Thu, 7 Feb 2008 23:22:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level:
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5
tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id YW+Tr9iNh2y7; Thu, 7 Feb 2008 23:22:45 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id C35A63A7E9F;
Thu, 7 Feb 2008 23:22:45 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 940F53A771E
for ; Thu, 7 Feb 2008 23:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id LsPNjt4pOdij for ;
Thu, 7 Feb 2008 23:22:44 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233])
by core3.amsl.com (Postfix) with ESMTP id 97F0B3A7E9F
for ; Thu, 7 Feb 2008 23:22:43 -0800 (PST)
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
m187O11k009878; Fri, 8 Feb 2008 09:24:08 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Feb 2008 09:23:44 +0200
Received: from esdhcp034233.research.nokia.com ([172.21.34.233]) by
esebh102.NOE.Nokia.com over TLS secured channel with Microsoft
SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 09:23:44 +0200
From: Lars Eggert
To: "tom.petch"
In-Reply-To: <00bd01c869ba$93689f80$0601a8c0@pc6>
Subject: Re: Test
X-Priority: 3
References: <035301c867fc$c78a2c80$0601a8c0@pc6>
<00bd01c869ba$93689f80$0601a8c0@pc6>
Message-Id: <965AFB39-2C26-4650-870D-157F6F6DBE4E@nokia.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 8 Feb 2008 09:23:43 +0200
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 08 Feb 2008 07:23:44.0440 (UTC)
FILETIME=[89906380:01C86A23]
X-Nokia-AV: Clean
Cc: discuss@ietf.org
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
On 2008-2-7, at 20:35, ext tom.petch wrote:
> In case you were wondering what I was on about, this mailing list is
> now
> discuss@ietf.org
Well, it used to be discuss@apps.ietf.org, and I guess the non-
secretariat apps server was retired?
Lars
From discuss-bounces@ietf.org Fri Feb 8 10:54:38 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id C719B28C446;
Fri, 8 Feb 2008 10:54:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level:
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5
tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=1,
J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QeX5LZHjasjn; Fri, 8 Feb 2008 10:54:38 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9639828C3AB;
Fri, 8 Feb 2008 10:54:38 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A03E428C38F
for ; Fri, 8 Feb 2008 10:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Btj1mWyKPdzQ for ;
Fri, 8 Feb 2008 10:54:36 -0800 (PST)
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org
[204.152.186.98])
by core3.amsl.com (Postfix) with ESMTP id 3C5FE28C37F
for ; Fri, 8 Feb 2008 10:54:36 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
by laweleka.osafoundation.org (Postfix) with ESMTP id 8057E142742
for ; Fri, 8 Feb 2008 10:56:08 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
port 10024) with ESMTP id hW5j7kZussP7 for ;
Fri, 8 Feb 2008 10:56:02 -0800 (PST)
Received: from [192.168.1.101] (unknown [74.95.2.169])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by laweleka.osafoundation.org (Postfix) with ESMTP id 146A914273D
for ; Fri, 8 Feb 2008 10:56:02 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
To: discuss@ietf.org
Message-Id:
Content-Type: multipart/alternative; boundary=Apple-Mail-4-851461741
From: Lisa Dusseault
Subject: Lisa's Apps Area Activity for Jan 2008
Date: Fri, 8 Feb 2008 10:56:01 -0800
X-Mailer: Apple Mail (2.752.3)
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
--Apple-Mail-4-851461741
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
Sending separately to working Discuss Apps address
Notes
A proposed charter for a revived IDN WG in the Apps area will be in
circulation shortly, assuming internal review goes well.
The ESDS BOF proposal was approved for Philadelphia: directory
service proposal geared for supply chain use cases.
Document Status and Progress
Active Documents: my action
- draft-ellermann-news-nntp-uri (Proposed Standard): I need to review
Stalled, in review, waiting on other:
- draft-ietf-sieve-body (Proposed Standard): DISCUSS from Tim Polk
needs resolution - waiting for response from Tim
- draft-adolf-dvb-urn (Informational): Needs new version to address
incomplete information about URN resolution
- draft-evain-ebu-urn (Informational): New version is in the I-D
queue... can probably approve imminently.
- draft-klensin-rfc2821bis (Draft Standard): IETF Last Call is
over, author and shepherd are taking some time before deciding how to
address last call issues.
- draft-ietf-sieve-notify-xmpp: same
- draft-creed-ogc-urn (Informational): Waiting for Cullen to clear
DISCUSS or revise it
- draft-ietf-sieve-notify-mailto: waiting on new version after IETF
last call
- draft-snell-atompub-bidi (Proposed Standard): author waiting on
some implementation feedback
- draft-ietf-imapext-sort (Proposed Standard) : waiting for authors
to revise or decide it's ready
- draft-wilde-sms-uri (Proposed Standard): Author considering what
to do about overlap with tel URIs.
Finished Processing -- RFC Ed queue and new RFCs
- draft-goodwin-iso-urn (Informational): Approved, waiting until
post-holiday processing to enter RFC queue
- draft-ietf-sieve-notify ( Proposed Standard): Approved, in RFC Ed
queue
- draft sjdcox-cgi-urn (Information): Approved, in RFC Ed queue
- RFC5228 (Standards Track): Sieve: An Email Filtering Language
- RFC5232 (Standards Track): Sieve Email Filtering: Imap4flags
Extension
- RFC5233 (Standards Track): Sieve Email Filtering: Subaddress
Extension
- RFC5235 (Standards Track): Sieve Email Filtering: Spamtest and
Virustest Extensions
- RFC5134 (Informational): A Uniform Resource Name Namespace for
the EPCglobal Electronic Product Code (EPC) and Related Standards
WG Status
no info
--Apple-Mail-4-851461741
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
Sending separately to =
working Discuss Apps address
Notes
A proposed =
charter for a revived IDN WG in the Apps area will be in circulation =
shortly, assuming internal review goes well.
The ESDS BOF proposal was approved for Philadelphia: =
directory service proposal geared for supply chain use cases.
Document =
Status and Progress
Active Documents: my action
=A0-=A0draft-ellermann-news-nntp-uri (Proposed =
Standard): I need to review
Stalled, in review, waiting on =
other:
=A0-=A0draft-ietf-sieve-body =
(Proposed Standard): DISCUSS from Tim Polk needs resolution - waiting =
for response from Tim
=A0-=A0draft-adolf-dvb-urn =
(Informational): Needs new version to address incomplete information =
about URN resolution
=A0-=A0draft-evain-ebu-urn =
(Informational): New version is in the I-D queue... can probably approve =
imminently.
=A0-=A0draft-klensin-rfc2821bis (Draft Standard): IETF Last =
Call is over, author and shepherd are taking some time before deciding =
how to address last call issues.
=A0- =
draft-ietf-sieve-notify-xmpp:=A0 same
=A0-=A0draft-creed-ogc-urn (Informational): Waiting for Cullen to =
clear DISCUSS or revise it
=A0- =
draft-ietf-sieve-notify-mailto:=A0waiting on new version after IETF last =
call
=A0-=A0draft-snell-atompub-bidi =
(Proposed Standard): author waiting on some implementation =
feedback
=A0-=A0draft-ietf-imapext-sort =
(Proposed Standard) : waiting for authors to revise or decide it's =
ready
=A0-=A0draft-wilde-sms-uri =
(Proposed Standard): Author considering what to do about overlap with =
tel URIs.
Finished Processing -- RFC Ed queue and new =
RFCs
=A0-=A0draft-goodwin-iso-urn =
(Informational): Approved, waiting until post-holiday processing to =
enter RFC queue
=A0- draft-ietf-sieve-notify ( =
Proposed Standard): Approved, in RFC Ed queue
=A0- draft sjdcox-cgi-urn (Information): Approved, =
in RFC Ed queue
=A0- RFC5228 (Standards =
Track):=A0Sieve: An Email Filtering Language
=A0- RFC5232 (Standards Track):=A0Sieve Email =
Filtering: Imap4flags Extension
=A0- RFC5233 =
(Standards Track):=A0Sieve Email Filtering: Subaddress =
Extension
=A0- RFC5235 (Standards =
Track):=A0Sieve Email Filtering: Spamtest and Virustest =
Extensions
=A0- RFC5134 (Informational):=A0A =
Uniform Resource Name Namespace for=A0the EPCglobal Electronic Product =
Code (EPC) and Related Standards
WG Status
=A0no =
info
=
--Apple-Mail-4-851461741--
From discuss-bounces@ietf.org Fri Feb 8 11:20:49 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5D46928C480;
Fri, 8 Feb 2008 11:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.263
X-Spam-Level:
X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=-1.407,
BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_35=0.6]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id YVnGBkM9dpXH; Fri, 8 Feb 2008 11:20:49 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2C36428C384;
Fri, 8 Feb 2008 11:20:49 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 25E7F28C384
for ; Fri, 8 Feb 2008 11:20:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id RlVX-2s0hEbs for ;
Fri, 8 Feb 2008 11:20:47 -0800 (PST)
Received: from mk-outboundfilter-1.mail.uk.tiscali.com
(mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37])
by core3.amsl.com (Postfix) with ESMTP id 291D528C378
for ; Fri, 8 Feb 2008 11:20:47 -0800 (PST)
X-Trace: 36959525/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.7
X-SBRS: None
X-RemoteIP: 62.241.163.7
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CACE7rEc+8aMH/2dsb2JhbABCiiCiCA
X-IP-Direction: IN
Received: from blaster.systems.pipex.net ([62.241.163.7])
by smtp.pipex.tiscali.co.uk with ESMTP; 08 Feb 2008 19:22:14 +0000
Received: from pc6 (1Cust171.tnt3.lnd4.gbr.da.uu.net [62.188.132.171])
by blaster.systems.pipex.net (Postfix) with SMTP id B859BE0000AD;
Fri, 8 Feb 2008 19:22:08 +0000 (GMT)
Message-ID: <002101c86a7f$3b9b8d60$0601a8c0@pc6>
From: "tom.petch"
To: "Lars Eggert"
References: <035301c867fc$c78a2c80$0601a8c0@pc6>
<00bd01c869ba$93689f80$0601a8c0@pc6>
<965AFB39-2C26-4650-870D-157F6F6DBE4E@nokia.com>
Subject: Re: Test
Date: Fri, 8 Feb 2008 09:22:22 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: discuss@ietf.org
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch"
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
Part of the migration announcement was that there was to be a signficant
flattening of the namespace, so for 'foo.ietf.org' to become 'ietf.org' was to
be expected, but I did expect the various 'foo' to become part of the local
part.
On the other hand, being 'discuss@ietf.org' could be said to reflect the
importance of apps among the various IETF areas:-)
Tom Petch
----- Original Message -----
From: "Lars Eggert"
To: "tom.petch"
Cc:
Sent: Friday, February 08, 2008 8:23 AM
Subject: Re: Test
> On 2008-2-7, at 20:35, ext tom.petch wrote:
> > In case you were wondering what I was on about, this mailing list is
> > now
> > discuss@ietf.org
>
> Well, it used to be discuss@apps.ietf.org, and I guess the non-
> secretariat apps server was retired?
>
> Lars
From discuss-bounces@ietf.org Fri Feb 8 15:59:35 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 7E20628C345;
Fri, 8 Feb 2008 15:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.187
X-Spam-Level:
X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5
tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Ty8TVL4rVBv9; Fri, 8 Feb 2008 15:59:35 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 49D883A7749;
Fri, 8 Feb 2008 15:59:35 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 55E8428C104
for ; Fri, 8 Feb 2008 15:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 88Sw2MIjrAhG for ;
Fri, 8 Feb 2008 15:59:32 -0800 (PST)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25])
by core3.amsl.com (Postfix) with ESMTP id 74E803A74D4
for ; Fri, 8 Feb 2008 15:59:32 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5])
by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
m19010oQ023926 for ; Sat, 9 Feb 2008 00:01:01 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,
v2.2) with ESMTP id m19010dr016776
for ; Fri, 8 Feb 2008 17:01:00 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id
m19010do015431
for ; Fri, 8 Feb 2008 18:01:00 -0600 (CST)
Received: (from nw141292@localhost)
by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m19010DB015430
for discuss@ietf.org; Fri, 8 Feb 2008 18:01:00 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to
Nicolas.Williams@sun.com using -f
Date: Fri, 8 Feb 2008 18:01:00 -0600
From: Nicolas Williams
To: discuss@ietf.org
Subject: NW-PP18 Web Authentication, TLS and phishing
Message-ID: <20080209000059.GI15878@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
[Lisa: feel free to re-post with a proper PP number.]
Abstract
Cryptographic user and server authentication, and cryptographic
transport protection are requirements for dealing with modern threat
models for the Internet.
Phish attacks aim to steal credentials, but if not credentials, then
man-in-the-middle (MITM) access.
It is important to ensure that user/service authentication and
cryptographic transport protection are cryptographically bound so as
to avoid MITM attacks.
Implied, of course, if authentication stronger than the current
reigning champion: username&password-over-TLS (which does not, and
cannot support channel binding).
Additionally, phishing opportunities must be limited, such as by
using authentication tokens that cannot be captured and played to
other relying parties. One goal is to push phishing opportunities to
the edge of the system: enrolment.
"Nigeria scam" type phishing is out of scope for this paper, but
phishing attacks where a user is directed to a malicious site (e.g.,
via spam e-mail) or where the user accidentally goes to a malicious
site (e.g., via typo-squatting) are in scope.
Introduction
Current practice for web authentication follows this pattern:
- The client is directed (or re-directed) to an https URL using...
- ...TLS with server certificate and anonymous client
- The page at the https URL contains an HTML form with username and
password text input fields; the form is [usually] POSTed via an
https URL
- When the browser posts said form the server sets a protected [and,
where encryption is not required, an unprotected] cookie
- Subsequent HTTP requests include said cookie, which contains or
points to server-side state indicating who the user is and that
they are authenticated
Web applications generally involve many HTTP requests, using HTTP as
a sort of reliable datagram transport. Usually multiple TCP
connections are used, with little multiplexing of HTTP requests
per-TCP connection.
A few observations:
- Username-and-password-over-TLS authentication is not very strong
- Stealing usernames and passwords is a common phish attack goal,
as those provide the access that attackers desire (e.g., to
one's bank accounts)
- Server certificates are only as good as the CAs that issue them
- There are a multitude of CAs, and browsers ship with large
trust anchor sets
- There is no true global PKI
- Server certificates are easy to obtain for typo and confusable
versions of legitimate domain names
- It is easy to obtain typo and confusable versions of
legitimate domain names; DNSSEC will not change this
- That said, cookies are a fine mechanism for associating a
multitude of HTTP requests with a given application session
- The use of cookies reduces the need for potentially expensive
authentication events
- If one think of a reliable datagram transport with built-in key
exchange, authentication and encryption, then one can see that
a protected cookie is a perfectly reasonable method of
associating datagrams with sessions, thus reducing the number
of authentication events needed per-session (there is plenty of
precedent for this too)
- So we need: better authentication of users and, possibly, servers
- And we need to make sure that this authentication is strongly
bound to the transport-layer encryption (TLS, in this case)
- Server authentication is already so bound
- Cryptographic binding of user and server authentication, and,
direct or indirect cryptographic binding of authentication to
key exchange and session cryptographic protection is required
to detect MITMs
I've been told several times that web authentication should happen at
the application layer. Often the rationale is that developers don't
like browsers' HTTP authentication dialogs, that they prefer to use
HTML forms so that they can have more control over the authentication
UI.
At the same time every one seems to agree that sending username and
password over TLS is a big part of the phishing problem, that we need
better authentication methods.
Arguments for why user authentication belongs in the application
layer, even when using something other than plain username&password,
can also be made. For example:
o Authentication at the application layer allows application control
over when it occurs, and application control over such UI elements
as are reasonable to put in the hands of the application
o Faster prototyping and more competition are possible if user
authentication takes place at the application layer; otherwise the
transport, browser and server stacks need to be re-deployed for
authentication mechanism that anyone invents.
On the other hand, one might argue that the difficulty of
deploying new authentication mechanisms is a defense against bad
authentication mechanisms, and that this is a good thing.
Channel Binding
The rest of this document assumes reader familiarity with the concept
of channel binding [RFC5056].
Briefly, channel binding is a concept, dating to the early 1990s,
where authentication at one layer is cryptographically bound to a
secure channel (e.g., a TLS session, or a set of TLS sessions), such
that no man-in-the-middle may exist when authentication with channel
binding succeeds. Channel binding functions just like the binding
between authentication and key exchange that protocols like IKE, TLS
and SSHv2 already do, but with authentication removed to a higher
network layer, usually the application layer.
Internet and Phishing Threat Model
Prior to the advent of phishing we have worried against a variety of
active and passive attacks on Internet protocols, particularly active
off-path attackers. But the rise of open wireless networks and the
rise of phishing mean that we must take passive attacks (e.g.,
eavesdropping) and active attacks (e.g., server impersonation, MITM
attacks) more seriously.
A modern threat model for web applications should include:
- passive attackers (e.g., eavesdroppers on open wireless networks)
- active off-path attackers (e.g., sender spoofing)
- active on-path attackers (e.g., MITMs)
- active mis-direction attacks (phish attacks)
- keeping in mind that phishers are after resources protected by
the user credentials that they usually try to steal
Federation
Until recently users needed a username and password for every site
and/or application that they used. This multiplicity of passwords is
difficult to manage, and quite frustrating to users. Thus, users
often use the same username and password across many unrelated sites,
which makes theft of their credentials all the more dangerous to the
users.
Merely replacing usernames and passwords with stronger authentication
methods may not reduce the number of identities that users must
manage, but it does present the opportunity to do so.
Assuming stronger authentication methods, one way to reduce the
number of identities per-user is to allow one identity and/or related
authentication infrastructure to be used for many sites. Credential
theft in such a model is mitigated by making it difficult for
attackers [who we assume do not have local access to the client] to
steal the credentials; theft of authentication tokens should not be
sufficient for impersonating the user.
Implied in this is trust transitivity. Identity federation supposes
islands of trust (as opposed to a global PKI, or other authentication
infrastructure). Trust is no inherently transitive, and breaks down
when trusted partners turn out to not be trustworthy, or as the trust
chains become too long (does one trust a story related by a friend
who heard it from a cousin who heard it from a friend who...?).
Transitive trust can be implemented badly. For example, if "bearer
token," asserting that the possessor is authenticated as some
identity, can be presented to any relying party that participates in
the associated identity federation, then theft of such a token can
lead to impersonation of the user.
On the other hand, small islands of trust present the opportunity for
white and black listing by the identity providers, which can be used
to help protect users from illegitimate sites.
Rapid Prototyping of Web Authentication
Various extensions to the JavaScript host environment on browsers
could greatly facilitate the development and deployment of
application-layer authentication for web applications.
For example:
- JavaScript bindings for existing authentication frameworks, such
as SASL and the GSS-API (see UI note below)
- JavaScript bindings for PKCS#11 and CMS/XMLdsig/XMLenc (see UI
note below)
- SAML APIs and JavaScript bindings for them (see UI note below)
- extensions to the XmlHttpRequest object to allow applications to
obtain the channel binding data for the request's TLS session
Consider, with JavaScript bindings for PKCS#11. Developers could use
low-level cryptographic primitives to implement PKI and ad-hoc public
key user authentication.
Frameworks like SASL and the GSS-API are probably more appropriate
(as the GSS-API does, or SASL soon will, support channel binding
already).
Of course, application access to authentication credentials through
such scripting interfaces MUST be suitably limited. For example, the
application MUST NOT be able to use such interfaces to generate
authentication messages suitable for impersonating the user to other
services. This can be done, in the case of SASL and GSS-API
interfaces, by not allowing the application to control the name of
the target service. Additionally, user control, over what
credentials a given application can access through such interfaces,
MUST be provided (for example, a one-time dialog where the user can
select an identity/credential to authenticate to a service as).
In the case of a PKCS#11 interface, it is important to understand
that not much control can be provided over what the application
encrypts or signs, but control can be provided over what keys it can
access. A PKCS#11 interface would probably put too much power in the
hands of the application, for the risk is probably great that keys
may be made available through it which are sensitive and which the
user does not understand that how to limit. However, a PKCS#11
interface would allow for rapid prototyping.
Enrolment
Interfaces for adding identities and raw credentials for use with
JavaScript interfaces to SASL, the GSS-API and/or SAML would be very,
very useful.
Ideally cryptographic user authentication methods, channel binding
and small trust islands (as small as one per-{user, service}) will
allow us to significantly reduce the possibility of phishing attacks
at all but the time when the user enrols their identity/credentials
with an identity provider and/or service.
We may not be able to exclude phishing attacks on enrolment, but
because enrolment is a rare event the opportunities for phishing
would still be greatly reduced, to the point where education may be
sufficient to make phishing very rare.
UIs, User Expectations and User Education
Even with significant improvements in web authentication it will
still be possible for phish attacks to succeed where users don't or
can't know about how a web page is protected. Experience tells us,
too, that users do not look at, nor know what to do with, server
certificates. We need UI elements that are simple and comprehensible
by most users, and which nonetheless convey critical security
information.
Perhaps the simplest piece of information that can be shown to the
user, and which conveys the most important information, is the
identity that was used to authenticate to a given service. This
assertion is predicated on having channel binding and either ad-hoc
per-{user, service} credentials or sufficiently small trust islands
(federations), for between the name of a service and the user's
identity, the user has enough information to decide whether the
session is legitimate.
Of course, if a user can be tricked into enrolling to a malicious
site such that: a) the site's name is similar to that of legitimate
sites, and b) the user's identity is similar to that which would be
used at legitimate sites, then the user can fail to realize when they
are being phished.
In the end phishing attacks are an on-line con-game. As with
con-games in the off-line world, human gullibility is the key, and no
technology can completely make up for human gullibility. By
deploying better web authentication we may be able to greatly reduce
phishing opportunities, but most likely we cannot prevent phishing
altogether. A web authentication scheme that requires phishers to
attack enrolment limits the opportunity for phishing to the point
where user education may have a chance.
Authentication Technologies
A number of authentication methods are possible that can support
channel binding:
- methods based on PK crypto (e.g., user certs, bare user public
keys, ala SSH)
- methods based on pre-shared symmetric keys
- methods based on passwords (e.g., challenge/response methods like
DIGEST-MD5)
- methods based on trusted key distribution (e.g., Kerberos V)
- combinations of the above
Radia Perlman and Charlie Kaufman have written a paper on
"User-centric PKI" which recommends the use of bare public keys to
identify users and the corresponding private keys to authenticate
them -- this is very similar to SSH publickey authentication. Using
certificates (which they also recommend as a supported mechanism)
allows for identity federation, effectively. Passwords, of course,
are the only truly portable authentication credential, at least until
smartcards and smartcard readers are ubiquitous. So protocols like
SACRED are recommended as a method of accessing private keys when
local tokens are not available.
Privacy Protection Considerations and Channel Binding
Letting identity providers (IdPs) know what service the user wants to
authenticate to allows the IdPs to perform white/blacklisting, and it
allows user authentication to be bound to the service name at the IdP
-- a useful property, in that it indirectly ensures channel binding.
However, it also allows IdPs to know what services the user is
accessing (and when).
User authentication methods that involve an IdP but which do not
involve sharing the names of the users' peers with the IdP are
clearly feasible, but it is crucial, in such cases, to get channel
binding right in the application protocol (or TLS, if user
authentication is being done in TLS).
Recommendations for Web Authentication
o Whether the future of web authentication entails application-layer
user authentication, or whether user authentication actually moves
into the TLS layer, the ability to detect MITM attacks is REQUIRED.
For example, sending a "bearer token" which can be presented to
many different relying parties is dangerous: there is no binding to
a particular session, therefore theft of such a token can enable
the thief to impersonate the authenticated user to other sites/
applications. All the thief needs to do is fool the user into
sending it the bearer token and then the thief can impersonate the
user to any site that would accept that token.
o Authentication messages MUST NOT be replay-able in other sessions
(see above) to other services.
o Use of plain username-and-password-over-TLS is NOT RECOMMENDED;
in fact, since it does not meet the above requirements, it MUST NOT
be used. Use of plain username-and-password-over-TLS to obtain
other forms of credentials, however, MAY be used.
o If user authentication moves to the transport layer (e.g., TLS),
and if its computational and/or bandwidth cost be significant, then
a method SHOULD be provided for a) controlling when TLS user
authentication is used, b) binding occasional user authentication
to a multiplicity of TLS sessions.
o Browser UIs MUST display the user's identity, used to authenticate
to a given site, as prominently as the name of the site and its
URL, whenever the authentication method used is: a) cryptographic
(not plain username&password), b) bound to the TLS sessions that
make up the application session.
[This section is left unfinished due to lack of time. RFC2119-like
terminology is used.]
From discuss-bounces@ietf.org Sun Feb 10 12:19:01 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 16CAB3A695D;
Sun, 10 Feb 2008 12:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.335
X-Spam-Level:
X-Spam-Status: No, score=0.335 tagged_above=-999 required=5
tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id GkFDdOwEYLPt; Sun, 10 Feb 2008 12:19:00 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8DC1C3A696C;
Sun, 10 Feb 2008 12:18:35 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 451BA3A696A
for ; Sun, 10 Feb 2008 12:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9KMCOfxg7EQU for ;
Sun, 10 Feb 2008 12:18:32 -0800 (PST)
Received: from outbound-mail-10.bluehost.com (outbound-mail-10.bluehost.com
[69.89.17.210]) by core3.amsl.com (Postfix) with SMTP id 41D5E3A63EC
for ; Sun, 10 Feb 2008 12:17:34 -0800 (PST)
Received: (qmail 22383 invoked by uid 0); 10 Feb 2008 20:19:00 -0000
Received: from unknown (HELO box7.bluehost.com) (69.89.30.147)
by mailproxy1.bluehost.com with SMTP; 10 Feb 2008 20:19:00 -0000
Received: from c-98-207-19-194.hsd1.ca.comcast.net ([98.207.19.194]
helo=KingsMountain.com)
by box7.bluehost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68)
(envelope-from )
id 1JOIdf-0001cs-4S; Sun, 10 Feb 2008 13:18:59 -0700
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-7) with nmh-1.1
Subject: pp7: draft-hodges-server-ident-check-00.txt
To: discuss@ietf.org
From: ' =JeffH '
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 10 Feb 2008 12:19:08 -0800
X-Identified-User: {32571:box7.bluehost.com:kingsmou:kingsmountain.com}
{sentby:bopbeforesmtp 98.207.19.194 authed with
kingsmountain.com}
Message-Id: <20080210201734.41D5E3A63EC@core3.amsl.com>
Cc: rlmorgan@washington.edu
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: discuss@ietf.org
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
Here's an I-D fresh off the press wrt pp7 - "Server Identity Check". I've also
submitted it to the I-D repository.
=JeffH
------
None J. Hodges
Internet-Draft NeuStar
Expires: August 13, 2008 R. Morgan
Internet2
February 10, 2008
Generic Server Identity Check
draft-hodges-server-ident-check-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Hodges & Morgan Expires August 13, 2008 [Page 1]
Internet-Draft Server Ident Check February 2008
Abstract
This document specifies the how an entity establishing a TLS
connection, or other PKI-based interaction, with a server should
verify the server identity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Server Identity Check . . . . . . . . . . . . . . . . . . . . . 5
3.1. Comparison of DNS Names . . . . . . . . . . . . . . . . . . 6
3.2. Comparison of IP Addresses . . . . . . . . . . . . . . . . 6
3.3. Comparison of Other subjectName Types . . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Hodges & Morgan Expires August 13, 2008 [Page 2]
Internet-Draft Server Ident Check February 2008
1. Introduction
Establishing a TLS-based connection with a server, or any other sort
of client-server PKI-based interaction, entails, on the part of the
client, verifying the "server's identity" based upon information
presented by the server in its certificate correlated with the
information about the server ensconced in the Domain Name System
(DNS).
Presently, various Internet-Drafts utilizing TLS or prescribing PKI-
based interactions, either prescribe their own server identity check,
or reference [RFC4513] or its predecesor, [RFC2830]. [there may be
other I-Ds referencing other specs that describe the equivalent of
server identity checks]
Converging our present understanding of this critical aspect of PKI-
based interactions is desirable in that it will hopefully encourage
more coherence in specifications and actual implementations thereof,
as well as ease the burden of crafting new specifications because
this aspect has been factored out and separately standardized.
This document extracts the "server identity check" section from
[RFC4513], with the goal of becoming a stand-alone BCP document
appropriately referenceable by I-Ds and thus RFCs.
Hodges & Morgan Expires August 13, 2008 [Page 3]
Internet-Draft Server Ident Check February 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Hodges & Morgan Expires August 13, 2008 [Page 4]
Internet-Draft Server Ident Check February 2008
3. Server Identity Check
In order to prevent man-in-the-middle attacks, the client MUST verify
the server's identity (as presented in the server's Certificate
message). In this section, the client's understanding of the
server's identity (typically the identity used to establish the
transport connection) is called the "reference identity".
The client may map the reference identity to a different type prior
to performing a comparison. Mappings may be performed for all
available subjectAltName types to which the reference identity can be
mapped; however, the reference identity should only be mapped to
types for which the mapping is either inherently secure (e.g.,
extracting the DNS name from a URI to compare with a subjectAltName
of type dNSName) or for which the mapping is performed in a secure
manner (e.g., using DNSSEC, or using user- or admin-configured host-
to-address/address-to-host lookup tables).
The server's identity may also be verified by comparing the reference
identity to the Common Name (CN) [RFC4519] value in the leaf Relative
Distinguished Name (RDN) of the subjectName field of the server's
certificate. This comparison is performed using the rules for
comparison of DNS names in Section 3.1.3.1, below, with the exception
that no wildcard matching is allowed. Although the use of the Common
Name value is existing practice, it is deprecated, and Certification
Authorities are encouraged to provide subjectAltName values instead.
Note that the TLS implementation may represent DNs in certificates
according to X.500 or other conventions. For example, some X.500
implementations order the RDNs in a DN using a left-to-right (most
significant to least significant) convention instead of LDAP's right-
to-left convention.
If the server identity check fails, user-oriented clients SHOULD
either notify the user (clients may give the user the opportunity to
continue with the LDAP session in this case) or close the transport
connection and indicate that the server's identity is suspect.
Automated clients SHOULD close the transport connection and then
return or log an error indicating that the server's identity is
suspect or both.
Beyond the server identity check described in this section, clients
should be prepared to do further checking to ensure that the server
is authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making
this determination.
Hodges & Morgan Expires August 13, 2008 [Page 5]
Internet-Draft Server Ident Check February 2008
3.1. Comparison of DNS Names
If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible
Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
before comparison with subjectAltName values of type dNSName.
Specifically, conforming implementations MUST perform the conversion
operation specified in Section 4 of RFC 3490 as follows:
o in step 1, the domain name SHALL be considered a "stored string";
o in step 3, set the flag called "UseSTD3ASCIIRules";
o in step 4, process each label with the "ToASCII" operation; and
o in step 5, change all label separators to U+002E (full stop).
After performing the "to-ASCII" conversion, the DNS labels and names
MUST be compared for equality according to the rules specified in
Section 3 of RFC3490.
The '*' (ASCII 42) wildcard character is allowed in subjectAltName
values of type dNSName, and then only as the left-most (least
significant) DNS label in that value. This wildcard matches any
left-most DNS label in the server name. That is, the subject
*.example.com matches the server names a.example.com and
b.example.com, but does not match example.com or a.b.example.com.
3.2. Comparison of IP Addresses
When the reference identity is an IP address, the identity MUST be
converted to the "network byte order" octet string representation
[RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
octet string will contain exactly four octets. For IP Version 6, as
specified in RFC 2460, the octet string will contain exactly sixteen
octets. This octet string is then compared against subjectAltName
values of type iPAddress. A match occurs if the reference identity
octet string and value octet strings are identical.
3.3. Comparison of Other subjectName Types
Client implementations MAY support matching against subjectAltName
values of other types as described in other documents.
Hodges & Morgan Expires August 13, 2008 [Page 6]
Internet-Draft Server Ident Check February 2008
4. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
Hodges & Morgan Expires August 13, 2008 [Page 7]
Internet-Draft Server Ident Check February 2008
Authors' Addresses
Jeff Hodges
NeuStar
2000 Broadway Street
Redwood City, CA 94063
US
Email: Jeff.Hodges@neustar.biz
RL 'Bob' Morgan
UWashington/Internet2
Seattle, WA
US
Email: rlmorgan@washington.edu
Hodges & Morgan Expires August 13, 2008 [Page 8]
Internet-Draft Server Ident Check February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hodges & Morgan Expires August 13, 2008 [Page 9]
---
end
From lorie@fujitsu.com Mon Feb 11 07:41:29 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F18143A6AEF
for ; Mon, 11 Feb 2008 07:41:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.971
X-Spam-Level:
X-Spam-Status: No, score=-7.971 tagged_above=-999 required=5
tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, DRUGS_ERECTILE=1,
DRUGS_ERECTILE_OBFU=1.5, FB_CIALIS_LEO3=3.899, FUZZY_CPILL=0.001,
GB_PHARMACY=1, HELO_DYNAMIC_DIALIN=3.384, HELO_EQ_DIP_DIALIN=1.573,
HOST_EQ_DIP_TDIAL=2.144, HTML_MESSAGE=1, J_CHICKENPOX_14=0.6,
MANGLED_CIALIS=2.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905,
RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_OBFU_PART_CIA=1.666,
SARE_OBFU_PART_IAL=1.666, SUBJECT_DRUG_GAP_C=0.003, SUBJ_BUY=0.001,
URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10,
URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BZVmEMc0IDgg
for ;
Mon, 11 Feb 2008 07:41:22 -0800 (PST)
Received: from p508D636F.dip.t-dialin.net (p508D636F.dip.t-dialin.net [80.141.99.111])
by core3.amsl.com (Postfix) with ESMTP id 37C9A3A6C68
for ; Mon, 11 Feb 2008 07:39:09 -0800 (PST)
Message-ID: <000801c86cc4$027458fb$20573eb6@ttitjo>
From: "dennet jerric"
To:
Subject: BUY CIIALIS GENERIC, order ciialis
Date: Mon, 11 Feb 2008 13:52:28 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0005_01C86CC4.026FB4A1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C86CC4.026FB4A1
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
nitrates are also found in some recreational drugs such as amyl nitrate =
or nitrite ("poppers"); or
C1ALIS - From a pharmacy that believes in providing excellent services =
and the cheapest pri_ces Cheap
------=_NextPart_000_0005_01C86CC4.026FB4A1
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
nitrates are also found in some recreational drugs such as amyl =
nitrate or nitrite ("poppers"); or
C1ALIS - From a =
pharmacy that believes in providing excellent services and the cheapest =
pri_ces Cheap
------=_NextPart_000_0005_01C86CC4.026FB4A1--
From discuss-bounces@ietf.org Mon Feb 11 18:41:35 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 566E728CB8D;
Mon, 11 Feb 2008 18:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ZFz6GfdyO+ip; Mon, 11 Feb 2008 18:41:35 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 294DD3A6E01;
Mon, 11 Feb 2008 18:41:35 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id ABFB828C734
for ; Mon, 11 Feb 2008 18:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id byvhO2Fr+4Gr for ;
Mon, 11 Feb 2008 18:41:33 -0800 (PST)
Received: from outbound-mail-116.bluehost.com (outbound-mail-116.bluehost.com
[69.89.22.16]) by core3.amsl.com (Postfix) with SMTP id D6C693A6E01
for ; Mon, 11 Feb 2008 18:41:32 -0800 (PST)
Received: (qmail 4381 invoked by uid 0); 12 Feb 2008 01:01:15 -0000
Received: from unknown (HELO box7.bluehost.com) (69.89.30.147)
by xmail.bluehost.com with SMTP; 12 Feb 2008 01:01:15 -0000
Received: from [216.239.45.19] (helo=KingsMountain.com)
by box7.bluehost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68)
(envelope-from ) id 1JOjWL-0003Rm-OA
for discuss@ietf.org; Mon, 11 Feb 2008 18:01:14 -0700
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-7) with nmh-1.1
Subject: wrt: PP8 PP9: synchron and pub/sub and push/pull
To: Apps Discuss
In-reply-to: Lisa Dusseault 's message of
Fri, 18 Jan 2008 11:01:51 -0800
From: ' =JeffH '
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 11 Feb 2008 17:01:19 -0800
X-Identified-User: {32571:box7.bluehost.com:kingsmou:kingsmountain.com}
{sentby:bopbeforesmtp 216.239.45.19 authed with
kingsmountain.com}
Message-Id: <20080212024132.D6C693A6E01@core3.amsl.com>
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ' =JeffH '
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
In interest of due diligence, folks discussing "synchronization" protocols
(and pub/sub and push/pull) ought to review (at least)..
Xerox PARC's Bayou Project
http://www2.parc.com/csl/projects/bayou/
SyncML
http://en.wikipedia.org/wiki/SyncML
=JeffH
From discuss-bounces@ietf.org Thu Feb 14 16:07:51 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 23AF228D00C;
Thu, 14 Feb 2008 16:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.521
X-Spam-Level: *
X-Spam-Status: No, score=1.521 tagged_above=-999 required=5 tests=[AWL=-0.642,
BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611,
RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 7Tiqn-pm2UYR; Thu, 14 Feb 2008 16:07:50 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 642EB3A690E;
Thu, 14 Feb 2008 16:07:50 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2A7D73A698E
for ; Thu, 14 Feb 2008 16:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nW-bf6DX-y97 for ;
Thu, 14 Feb 2008 16:07:48 -0800 (PST)
Received: from ee01.elistx.com (ee01.elistx.com [67.155.182.182])
by core3.amsl.com (Postfix) with ESMTP id 7BC5B3A690E
for ; Thu, 14 Feb 2008 16:07:48 -0800 (PST)
Received: from CONVERSION-DAEMON.elistx.com by elistx.com
(PMDF V6.3-2x2 #31546) id <0JW900901713XH@elistx.com> for
discuss@apps.ietf.org; Thu, 14 Feb 2008 19:07:51 -0500 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by elistx.com (PMDF V6.3-2x2 #31546) with ESMTP id
<0JW90093B71370@elistx.com>
for discuss@apps.ietf.org; Thu, 14 Feb 2008 19:07:51 -0500 (EST)
Date: Thu, 14 Feb 2008 19:08:14 -0500
From: James Galvin
Subject: this is a test
To: discuss@apps.ietf.org
Message-id:
MIME-version: 1.0
X-Mailer: Mulberry/4.0.7 (Win32)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
Sorry to burden the list with this but I need to do this to make
sure it really does work end to end.
Jim
From discuss-bounces@ietf.org Fri Feb 15 08:40:45 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E622C28D260;
Fri, 15 Feb 2008 08:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.265
X-Spam-Level:
X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=2.000,
BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ZWSfX9l7YBA6; Fri, 15 Feb 2008 08:40:45 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B636D3A6AAE;
Fri, 15 Feb 2008 08:40:45 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D90963A6AAE
for ; Fri, 15 Feb 2008 08:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id h1dKS7lUk6fM for ;
Fri, 15 Feb 2008 08:40:43 -0800 (PST)
Received: from ee01.elistx.com (ee01.elistx.com [67.155.182.182])
by core3.amsl.com (Postfix) with ESMTP id F2B053A6874
for ; Fri, 15 Feb 2008 08:40:42 -0800 (PST)
Received: from CONVERSION-DAEMON.elistx.com by elistx.com
(PMDF V6.3-2x2 #31546) id <0JWA00901GXLPY@elistx.com> for
discuss@apps.ietf.org; Fri, 15 Feb 2008 11:39:21 -0500 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by elistx.com (PMDF V6.3-2x2 #31546) with ESMTP id
<0JWA007MMGXL0G@elistx.com>
for discuss@apps.ietf.org; Fri, 15 Feb 2008 11:39:21 -0500 (EST)
Date: Fri, 15 Feb 2008 11:40:14 -0500
From: James Galvin
Subject: what lists are in apps.ietf.org?
To: discuss@apps.ietf.org
Message-id:
MIME-version: 1.0
X-Mailer: Mulberry/4.0.7 (Win32)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
First let me apologize that email to apps.ietf.org stopped working.
It certainly was not planned that way. Worse, there was an early
ticket from Dave Crocker pointing out there was an issue but even
this got overlooked in the stream of issues that cried out for
attention.
Unfortunately, since apps.ietf.org is a delegated domain, the
default action for tickets of this type was to defer to those third
parties. This actually worked until we looked closer at what was
going on with email and realized that the DNS configuration was
part of the problem. apps.ietf.org was unique in this respect
compared to all the other "third party domains". Sorry, but that
contributed to the oversight. I could explain all this in way too
much detail but, frankly, it would sound like an excuse and it's
really not important right now.
The problem now is that there is no information as to what mailing
lists are in the apps.ietf.org domain. I am aware of the following
three:
discuss
urn-nid
w3c-policy
The discuss list now works and the other two will work soon
(today). There is a mapping rule that has to be added to the email
system to make things work the way you would expect given the
configuration of apps.ietf.org.
If you own a list in the apps.ietf.org domain would you please
self-declare by sending a message to me and I'll make sure the
mapping gets entered and your list starts working again.
Thanks,
Jim
From discuss-bounces@ietf.org Mon Feb 18 03:43:45 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 20DA428C34F;
Mon, 18 Feb 2008 03:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.067
X-Spam-Level: ***
X-Spam-Status: No, score=3.067 tagged_above=-999 required=5 tests=[AWL=-0.139,
BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,
J_CHICKENPOX_23=0.6, RCVD_IN_NJABL_RELAY=2.696]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id J3k5P12i2Ytz; Mon, 18 Feb 2008 03:43:44 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E96D928C327;
Mon, 18 Feb 2008 03:43:44 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4175728C349
for ; Mon, 18 Feb 2008 03:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 8ZctpPYdny55 for ;
Mon, 18 Feb 2008 03:43:42 -0800 (PST)
Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp
[133.2.251.194])
by core3.amsl.com (Postfix) with ESMTP id DA1E328C326
for ; Mon, 18 Feb 2008 03:43:41 -0800 (PST)
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16])
by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id
m1IBhb7M010585
for ; Mon, 18 Feb 2008 20:43:37 +0900 (JST)
Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp
id 1da5_be39e7de_de16_11dc_8a84_0014221fa3c9;
Mon, 18 Feb 2008 20:43:37 +0900
Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33208)
by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server]
id for from ;
Mon, 18 Feb 2008 20:39:14 +0900
Message-Id: <6.0.0.20.2.20080218203629.058cf7c0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Mon, 18 Feb 2008 20:39:31 +0900
To: discuss@ietf.org
From: Martin Duerst
Subject: Fwd: I-D Action:draft-duerst-iana-namespace-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
Based on some earlier discussion on this list and some encouragement
by Chris, Tim Bray and myself wrote a proposal for HTTP namespace
URI registration with IANA. Comments appreciated.
Regards, Martin.
>To: i-d-announce@ietf.org
>From: Internet-Drafts@ietf.org
>Subject: I-D Action:draft-duerst-iana-namespace-00.txt
>Date: Mon, 18 Feb 2008 03:30:01 -0800 (PST)
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title : HTTP-based IETF Namespace URIs at IANA
> Author(s) : M. Duerst, T. Bray
> Filename : draft-duerst-iana-namespace-00.txt
> Pages : 8
> Date : 2008-02-18
>
>This document creates a registry and defines a procedure to allow
>IETF specifications to register XML Namespace Names with IANA which
>are HTTP URIs and thus potentially useful for looking up information
>about the namespace.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-duerst-iana-namespace-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>i-d-announce-request@ietf.org with the word unsubscribe in the body of
>the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username "anonymous" and a password of your e-mail address. After
>logging in, type "cd internet-drafts" and then
> "get draft-duerst-iana-namespace-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
> mailserv@ietf.org.
>In the body type:
> "FILE /internet-drafts/draft-duerst-iana-namespace-00.txt".
>
>NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <2008-02-18032741.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-duerst-iana-namespace-00.txt
>
>
>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>http://www.ietf.org/mailman/listinfo/i-d-announce
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
From discuss-bounces@ietf.org Mon Feb 18 10:10:08 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id DAC8C3A6D4A;
Mon, 18 Feb 2008 10:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.349
X-Spam-Level:
X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5
tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=1,
J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id reQFL6CF+Qpl; Mon, 18 Feb 2008 10:10:08 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8071228C22B;
Mon, 18 Feb 2008 10:10:08 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2654D3A6C5D
for ; Mon, 18 Feb 2008 10:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id qDKGhaCfwsQ1 for ;
Mon, 18 Feb 2008 10:10:04 -0800 (PST)
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org
[204.152.186.98])
by core3.amsl.com (Postfix) with ESMTP id 90A3028C350
for ; Mon, 18 Feb 2008 10:09:40 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
by laweleka.osafoundation.org (Postfix) with ESMTP id 657AB142774;
Mon, 18 Feb 2008 10:09:41 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id cHTkMEPSq5D3; Mon, 18 Feb 2008 10:09:32 -0800 (PST)
Received: from [192.168.1.101] (unknown [74.95.2.169])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by laweleka.osafoundation.org (Postfix) with ESMTP id AA17414274D;
Mon, 18 Feb 2008 10:09:29 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
References: <6.0.0.20.2.20080218203629.058cf7c0@localhost>
Content-Type: multipart/alternative; boundary=Apple-Mail-2--434819080
Message-Id: <048BF0AB-6FCB-411B-AD4B-726DF8B13B08@osafoundation.org>
From: Lisa Dusseault
Subject: Re: I-D Action:draft-duerst-iana-namespace-00.txt
Date: Mon, 18 Feb 2008 10:09:23 -0800
To: IANA , Thomas Narten ,
Mark Nottingham
X-Mailer: Apple Mail (2.752.3)
Cc: Tim Bray , Apps Discuss
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
--Apple-Mail-2--434819080
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
Hi,
I'm adding IANA and Thomas Narten (author of IANA considerations
docs) to this thread to get early IANA feedback about this idea. It
may well be a good idea, but we definitely want to think it through:
- A registry for HTTP URLs in the IANA domain
... including a HTML or XML document hosted by IANA on its
Website at the location specified in the registered URL
... which means that end-users and developers will use these URIs,
perhaps very frequently
What do we know about the W3 experience hosting namespace URIs with
actual documents at the URIs? I've been hearing rumours lately about
something like this causing expensive levels of traffic, but I can't
recall the details.
Lisa
Begin forwarded message:
> From: Martin Duerst
> Date: February 18, 2008 3:39:31 AM PST
> To: discuss@ietf.org
> Subject: Fwd: I-D Action:draft-duerst-iana-namespace-00.txt
>
> Based on some earlier discussion on this list and some encouragement
> by Chris, Tim Bray and myself wrote a proposal for HTTP namespace
> URI registration with IANA. Comments appreciated.
>
> Regards, Martin.
>
>> To: i-d-announce@ietf.org
>> From: Internet-Drafts@ietf.org
>> Subject: I-D Action:draft-duerst-iana-namespace-00.txt
>> Date: Mon, 18 Feb 2008 03:30:01 -0800 (PST)
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> Title : HTTP-based IETF Namespace URIs at IANA
>> Author(s) : M. Duerst, T. Bray
>> Filename : draft-duerst-iana-namespace-00.txt
>> Pages : 8
>> Date : 2008-02-18
>>
>> This document creates a registry and defines a procedure to allow
>> IETF specifications to register XML Namespace Names with IANA which
>> are HTTP URIs and thus potentially useful for looking up information
>> about the namespace.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-duerst-iana-
>> namespace-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the
>> body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-duerst-iana-namespace-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> mailserv@ietf.org.
>> In the body type:
>> "FILE /internet-drafts/draft-duerst-iana-namespace-00.txt".
>>
>> NOTE: The mail server at ietf.org can return the document in
>> MIME-encoded form by using the "mpack" utility. To use this
>> feature, insert the command "ENCODING mime" before the "FILE"
>> command. To decode the response(s), you will need "munpack" or
>> a MIME-compliant mail reader. Different MIME-compliant mail
>> readers
>> exhibit different behavior, especially when dealing with
>> "multipart" MIME messages (i.e. documents which have been split
>> up into multiple messages), so check your local
>> documentation on
>> how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>> Content-Type: text/plain
>> Content-ID: <2008-02-18032741.I-D@ietf.org>
>>
>> ENCODING mime
>> FILE /internet-drafts/draft-duerst-iana-namespace-00.txt
>>
>>
>> > namespace-00.txt>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> http://www.ietf.org/mailman/listinfo/i-d-announce
>
>
> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-# http://www.sw.it.aoyama.ac.jp
> mailto:duerst@it.aoyama.ac.jp
>
--Apple-Mail-2--434819080
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
Hi,
I'm adding IANA and Thomas =
Narten (author of IANA considerations docs) to this thread to get early =
IANA feedback about this idea.=A0 It may well be a good idea, but we =
definitely want to think it through:
=A0- A registry for HTTP =
URLs in the IANA domain
=A0 =A0... including a HTML or XML =
document hosted by IANA on its Website at the location specified in the =
registered URL
=A0 ... which means that end-users and =
developers will use these URIs, perhaps very frequently
What do we know about the =
W3 experience hosting namespace URIs with actual documents at the URIs?=A0=
I've been hearing rumours lately about something like this causing =
expensive levels of traffic, but I can't recall the =
details.
Lisa
Begin =
forwarded message:
Date: February 18, 2008 3:39:31 AM =
PST
Subject: =
Fwd: I-D Action:draft-duerst-iana-namespace-00.txt=A0
Based =
on some earlier discussion on this list and some encouragement
by Chris, Tim Bray and myself wrote a proposal for =
HTTP namespace
URI registration with IANA. =
Comments appreciated.
Regards, =A0 Martin.
Subject: I-D =
Action:draft-duerst-iana-namespace-00.txt=A0
Date: =
Mon, 18 Feb 2008 03:30:01 -0800 (PST)
A New Internet-Draft is =
available from the on-line Internet-Drafts directories.
=A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP-based =
IETF Namespace URIs at IANA
=A0 =A0 =A0 Author(s) =A0 =A0 =A0 : M. Duerst, T. =
Bray
=A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : =
draft-duerst-iana-namespace-00.txt
=A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =
Date=A0 =A0 =A0 =A0 =A0 =A0 =
: 2008-02-18
This document creates a registry =
and defines a procedure to allow
IETF =
specifications to register XML Namespace Names with IANA which
are HTTP URIs and thus potentially useful for =
looking up information
about the =
namespace.
A URL for this Internet-Draft is:
To remove yourself from the I-D Announcement list, =
send a message to
the =
message.
to =
change your subscription settings.
Internet-Drafts are also =
available by anonymous FTP. Login with the=A0
username =
"anonymous" and a password of your e-mail address. After=A0
logging =
in, type "cd internet-drafts" and then
=A0 =A0 =A0 "get =
draft-duerst-iana-namespace-00.txt".
A list of Internet-Drafts =
directories can be found in
Internet-Drafts can also be =
obtained by e-mail.
Send a message to:
In the body type:
=A0 =A0 =A0 "FILE =
/internet-drafts/draft-duerst-iana-namespace-00.txt".
NOTE: =
=A0 The mail server at =
ietf.org can return the document in
=A0 =A0 =A0 MIME-encoded form by =
using the "mpack" utility.=A0 =
To use this
=A0 =A0 =A0 feature, insert the =
command "ENCODING mime" before the "FILE"
=A0 =A0 =A0 command.=A0 To decode the response(s), =
you will need "munpack" or
=A0 =A0 =A0 a MIME-compliant mail =
reader.=A0 Different =
MIME-compliant mail readers
=A0 =A0 =A0 exhibit different =
behavior, especially when dealing with
=A0 =A0 =A0 "multipart" MIME =
messages (i.e. documents which have been split
=A0 =A0 =A0 =
up into multiple messages), so check your local documentation =
on
=A0 =A0 =A0=
how to manipulate these messages.
Below is the =
data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII =
version of the
Internet-Draft.
Content-Type: text/plain
ENCODING mime
FILE =
/internet-drafts/draft-duerst-iana-namespace-00.txt
_______________________________________________
I-D-Announce mailing list
#-#-#=A0 Martin J. Du"rst, Assoc. =
Professor, Aoyama Gakuin University
=
=
--Apple-Mail-2--434819080--
From discuss-bounces@ietf.org Mon Feb 18 10:18:21 2008
Return-Path:
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CC90E28C44B;
Mon, 18 Feb 2008 10:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.166
X-Spam-Level:
X-Spam-Status: No, score=-1.166 tagged_above=-999 required=5 tests=[AWL=0.811,
BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id C5K1oJIavgKu; Mon, 18 Feb 2008 10:18:21 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9C4F328C342;
Mon, 18 Feb 2008 10:18:21 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id EB4E228C342
for ; Mon, 18 Feb 2008 10:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ag3J6l0ouN6U for ;
Mon, 18 Feb 2008 10:18:19 -0800 (PST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181])
by core3.amsl.com (Postfix) with ESMTP id 4B0FC28C22B
for ; Mon, 18 Feb 2008 10:18:19 -0800 (PST)
Received: by wa-out-1112.google.com with SMTP id m16so2850859waf.20
for ; Mon, 18 Feb 2008 10:18:16 -0800 (PST)
Received: by 10.114.177.1 with SMTP id z1mr1171551wae.7.1203358696053;
Mon, 18 Feb 2008 10:18:16 -0800 (PST)
Received: by 10.114.159.16 with HTTP; Mon, 18 Feb 2008 10:18:16 -0800 (PST)
Message-ID: <517bf110802181018y258276c9u9d866bebecd44a68@mail.gmail.com>
Date: Mon, 18 Feb 2008 10:18:16 -0800
From: "Tim Bray"
To: "Lisa Dusseault"
Subject: Re: I-D Action:draft-duerst-iana-namespace-00.txt
In-Reply-To: <048BF0AB-6FCB-411B-AD4B-726DF8B13B08@osafoundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6.0.0.20.2.20080218203629.058cf7c0@localhost>
<048BF0AB-6FCB-411B-AD4B-726DF8B13B08@osafoundation.org>
X-Google-Sender-Auth: 9eefae625e31a870
Cc: Thomas Narten , Tim Bray ,
Mark Nottingham , IANA ,
Apps Discuss
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: tbray@textuality.com
List-Id: general discussion of application-layer protocols
List-Unsubscribe: ,
List-Post:
List-Help: