From simple-bounces@ietf.org Thu May 1 14:13:21 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A6D4E3A6E25;
Thu, 1 May 2008 14:13:21 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id EDA653A6D09;
Thu, 1 May 2008 14:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000,
BAYES_00=-2.599, SPF_PASS=-0.001]
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 BhJRiMpfMIyu; Thu, 1 May 2008 14:13:18 -0700 (PDT)
Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2])
by core3.amsl.com (Postfix) with ESMTP id BBDAD3A6A19;
Thu, 1 May 2008 14:13:17 -0700 (PDT)
Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121])
(authenticated bits=0)
by nostrum.com (8.14.2/8.14.1) with ESMTP id m41LDIG7033685
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Thu, 1 May 2008 16:13:18 -0500 (CDT)
(envelope-from rjsparks@nostrum.com)
Message-Id:
From: Robert Sparks
To: "sip@ietf.org List" , simple mailing list ,
mmusic@ietf.org
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 1 May 2008 16:13:17 -0500
X-Mailer: Apple Mail (2.919.2)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
mechanism)
X-Virus-Scanned: ClamAV 0.93/6802/Wed Apr 16 12:35:44 2008 on
shaman.nostrum.com
X-Virus-Status: Clean
Subject: [Simple] SIPit 22 summary
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Robert Sparks
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Apologies for the delay in getting this to the lists - the survey
software I've been using did something surprising and I had to go
unravel a lot of information by hand. I will be using some other tool
going forward.
You can see the summary from SIPit 22 at https://www.sipit.net/SIPit22_Summary
Please don't reply to this cross-posted message. Send a post directly
to the appropriate list instead.
Thanks,
RjS
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Mon May 5 04:15:04 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1C18F28C32D;
Mon, 5 May 2008 04:15:04 -0700 (PDT)
X-Original-To: simple@ietf.org
Delivered-To: simple@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0)
id CB15528C28C; Mon, 5 May 2008 04:15:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080505111501.CB15528C28C@core3.amsl.com>
Date: Mon, 5 May 2008 04:15:01 -0700 (PDT)
Cc: simple@ietf.org
Subject: [Simple] I-D Action:draft-ietf-simple-xcap-diff-09.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.
Title : An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources
Author(s) : J. Rosenberg, J. Urpalainen
Filename : draft-ietf-simple-xcap-diff-09.txt
Pages : 16
Date : 2008-05-05
This specification defines a document format that can be used to
indicate that a change has occurred in a document managed by the
Extensible Markup Language (XML) Configuration Access Protocol
(XCAP). This format indicates the document that has changed and its
former and new entity tags. It also can indicate the specific change
that was made in the document, using an XML patch format. This
format allows also indications of element and attribute content of an
XML document. XCAP diff documents can be delivered to clients using
a number of means, including a Session Initiation Protocol (SIP)
event package.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-09.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Message/External-body;
name="draft-ietf-simple-xcap-diff-09.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-05-05040555.I-D@ietf.org>
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
--NextPart--
From simpldogdd@mminternet.com Wed May 7 13:17:58 2008
Return-Path:
X-Original-To: ietfarch-simple-archive@core3.amsl.com
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 147FE3A6DB5
for ; Wed, 7 May 2008 13:17:58 -0700 (PDT)
X-Quarantine-ID:
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA
\256 Official Site [...]
X-Spam-Flag: NO
X-Spam-Score: -9.886
X-Spam-Level:
X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5
tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597,
FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2,
HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875,
HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001,
HTML_SHORT_LINK_IMG_3=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3,
MIME_HTML_ONLY=1.457, 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_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905,
RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_BLACK=20,
URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10,
URIBL_WS_SURBL=10, URI_NOVOWEL=1.62, 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 scqQp-BzkTZy
for ;
Wed, 7 May 2008 13:17:58 -0700 (PDT)
Received: from core.humlnet.cz (core.humlnet.cz [195.39.26.142])
by core3.amsl.com (Postfix) with SMTP id 89A383A714E
for ; Wed, 7 May 2008 13:17:54 -0700 (PDT)
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Message-Id: <20080507111755.8108.qmail@core.humlnet.cz>
To:
Subject: Dear simple-archive@ietf.org May 89% 0FF
From: VIAGRA ® Official Site
MIME-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Date: Wed, 7 May 2008 13:17:54 -0700 (PDT)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service
advertised. Prices and item availability subject to change without notice.
Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From RadonMitigation@mail.com Thu May 8 14:35:03 2008
Return-Path:
X-Original-To: ietfarch-simple-archive@core3.amsl.com
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 7314F28C348
for ; Thu, 8 May 2008 14:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.488
X-Spam-Level: ****
X-Spam-Status: No, score=4.488 tagged_above=-999 required=5 tests=[AWL=-0.151,
BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_FONT_SIZE_LARGE=0.001,
HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001,
RCVD_IN_BL_SPAMCOP_NET=1.96]
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 rnWwPfMOt-gq
for ;
Thu, 8 May 2008 14:35:03 -0700 (PDT)
Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33])
by core3.amsl.com (Postfix) with SMTP id 2563928C32C
for ; Thu, 8 May 2008 14:35:03 -0700 (PDT)
Received: (qmail 24929 invoked from network); 8 May 2008 21:35:00 -0000
Received: from unknown (69.129.151.158)
by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 08 May 2008 21:34:58 -0000
From: "Radon Mitigation"
To: "simple-archive"
Subject: Radon
Date: Thu, 8 May 2008 17:35:03 -0400
Organization: Air Quality Control
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_NextPart_000_0000_01C6527E.AE8904D0"
Message-Id: <20080508213503.2563928C32C@core3.amsl.com>
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01C6527E.AE8904D0
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0001_01C6527E.AE8904D0"
------=_NextPart_001_0001_01C6527E.AE8904D0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
I hope that you had a great weekend!
To show our appreciation to the Indiana Realtors who refer their clients to us every time radon becomes an issue, we wanted to take this opportunity to send you our latest coupon. By giving this to your clients, they can save $100 off the cost of a radon reduction system. Feel free to print it, copy it, save it for future use, or share it with your clients & co-workers.
We look forward to a long-term relationship with you and your clients!
Sincerely;
The Radon Removal Team at
Air Quality Control
The #1 Radon Specialist in Indiana!
1-800-420-3881
If you would like to be removed from our customer list, please send an email with the word "remove" to: TakeOffList@usa.com
------=_NextPart_001_0001_01C6527E.AE8904D0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
I hope that you had a great weekend!
To show our appreciation to the Indiana Realtors who
refer their clients to us every time radon becomes an issue, we wanted
to take this opportunity to send you our latest coupon. By giving this to
your clients, they can save $100 off the cost of a radon reduction system.
Feel free to print it, copy it, save it for future use, or share it with your
clients & co-workers.
We look forward to a long-term relationship
with you and your clients!
-------------------------------------------------------------------------=
---------------
Dear Google AdWords Customer,
We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info=
rmation.
-------------------------------------------------------------------------=
---
This message was sent from a notification-only email address that does
not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------=
----
------=_NextPart_000_0CCC_01C8B487.C6442B00--
From simple-bounces@ietf.org Tue May 13 02:24:07 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E9C503A67A5;
Tue, 13 May 2008 02:24:06 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F278E28C2D3
for ; Tue, 13 May 2008 02:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
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 KYi4wyDs0G-n for ;
Tue, 13 May 2008 02:24:04 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 367A528C2CE
for ; Tue, 13 May 2008 02:24:04 -0700 (PDT)
Received: from [124.17.15.2] (port=29905 helo=[172.31.13.25])
by gs19.inmotionhosting.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from )
id 1Jvpg1-0004KL-Gj
for simple@ietf.org; Tue, 13 May 2008 01:16:05 -0700
Message-Id:
From: Eric Burger
To: simple@ietf.org
Mime-Version: 1.0 (Apple Message framework v912)
Date: Tue, 13 May 2008 16:02:23 +0800
X-Mailer: Apple Mail (2.912)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [Simple] in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Why do we have a field in an IMDN?
It cannot be for correlation, as the sender MUST have a Message-ID.
It cannot be for letting the user what the message is, because we are
talking about IMs here, not e-mails.
It cannot be for displaying status to the IM sender, because the IM
Recipient UA has no idea what the locale of the sender is and will
undoubtably use the wrong language and character set.
It could be used as a spam attack vector, but that would be silly of
us to build in to a protocol.
Does ANYONE object to simply taking out the field?
Does ANYONE want the field to be present?
Please respond to the list ASAP, as this document is WAY overdue.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Tue May 13 16:20:04 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E845F3A67F1;
Tue, 13 May 2008 16:20:04 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 3F8423A67F1
for ; Tue, 13 May 2008 16:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 krYKL1-5uIiM for ;
Tue, 13 May 2008 16:20:02 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229])
by core3.amsl.com (Postfix) with ESMTP id 2CECD3A67AF
for ; Tue, 13 May 2008 16:20:02 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so2974672rvf.49
for ; Tue, 13 May 2008 16:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
bh=eInDOaPyi4+ns9PBSWcVMZPU4Tv0XwGkUQ/D4cFUQP0=;
b=IvuvCqikR254xlaNkpdkVA8N2ebXi6hbrXviJ5WIpk1zHMYsUhrUylqvebQHe8PdmYzebggGKQBYG6zkRHYJuYL8QCq73S9SB2QiSy6fAW2qa9b+SsFG42Vi5bH6z2kcQmPEVGVw1qT4jJfCF373XuhSX4lbtIWeZJGmajkc7wY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
b=gUk5Nd2SWMMUITuuuMrL7z5i8pVeHCY2MN6viH8sd4cqXkmKsmJ94KDiSGt1j7lBBwc6dupYQ9/ywzQnPTZ0tJo+nOiX1pbVaJYlLfmu+MeUdJ+3isFr2XM9ZxO32XeHZzU/EriceYhudVZBf6gNuKVFP98lQDA6eqZTAEc6hPQ=
Received: by 10.114.191.12 with SMTP id o12mr287893waf.224.1210720657718;
Tue, 13 May 2008 16:17:37 -0700 (PDT)
Received: by 10.114.235.10 with HTTP; Tue, 13 May 2008 16:17:37 -0700 (PDT)
Message-ID: <66cd252f0805131617nc6b20daq939c08faf6af944e@mail.gmail.com>
Date: Wed, 14 May 2008 09:17:37 +1000
From: "Hisham Khartabil"
To: "Eric Burger"
In-Reply-To:
MIME-Version: 1.0
References:
Cc: simple@ietf.org
Subject: Re: [Simple] in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============1307531459=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
--===============1307531459==
Content-Type: multipart/alternative;
boundary="----=_Part_9575_23330430.1210720657597"
------=_Part_9575_23330430.1210720657597
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
It for the IMDN to carry extra information about the IM. For example,
information on why it was not delivered.
34jk324j2006-04-04T12:16:49-05:00im:bob@example.com
im:bob@example.com The IM could not be delivered due to network
failure
On 13/05/2008, Eric Burger wrote:
>
> Why do we have a field in an IMDN?
>
> It cannot be for correlation, as the sender MUST have a Message-ID.
>
> It cannot be for letting the user what the message is, because we are
> talking about IMs here, not e-mails.
>
> It cannot be for displaying status to the IM sender, because the IM
> Recipient UA has no idea what the locale of the sender is and will
> undoubtably use the wrong language and character set.
>
> It could be used as a spam attack vector, but that would be silly of
> us to build in to a protocol.
>
> Does ANYONE object to simply taking out the field?
> Does ANYONE want the field to be present?
>
> Please respond to the list ASAP, as this document is WAY overdue.
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>
------=_Part_9575_23330430.1210720657597
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
It for the IMDN to carry extra information about the IM. For example, information on why it was not delivered.
<?xml version="1.0" encoding="UTF-8"?> <imdn xlmns="urn:ietf:params:xml:ns:imdn"> <message-id>34jk324j</message-id> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri> <original-recipient-uri> im:bob@example.com
</original-recipient-uri> <disposition> <delivery/> </disposition> <status> <failed/> </status> <note lang="en">The IM could not be delivered due to network failure</note>
</imdn>
It cannot be for correlation, as the sender MUST have a Message-ID.
It cannot be for letting the user what the message is, because we are talking about IMs here, not e-mails.
It cannot be for displaying status to the IM sender, because the IM Recipient UA has no idea what the locale of the sender is and will
undoubtably use the wrong language and character set.
It could be used as a spam attack vector, but that would be silly of us to build in to a protocol.
Does ANYONE object to simply taking out the field?
Does ANYONE want the field to be present?
------=_Part_9575_23330430.1210720657597--
--===============1307531459==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
--===============1307531459==--
From simple-bounces@ietf.org Tue May 13 17:47:54 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9E89C3A67D8;
Tue, 13 May 2008 17:47:54 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CD5953A67D8
for ; Tue, 13 May 2008 17:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.805
X-Spam-Level:
X-Spam-Status: No, score=-4.805 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041,
MIME_BASE64_TEXT=1.753, 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 gIuDzhfLIV28 for ;
Tue, 13 May 2008 17:47:51 -0700 (PDT)
Received: from smtp03.bis.na.blackberry.com (smtp03.bis.na.blackberry.com
[216.9.248.50]) by core3.amsl.com (Postfix) with ESMTP id E89033A67AF
for ; Tue, 13 May 2008 17:47:50 -0700 (PDT)
Received: from bda381.bisx.prod.on.blackberry (bda381.bisx.prod.on.blackberry
[172.20.234.81])
by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id
m4E0joDG018410; Wed, 14 May 2008 00:45:50 GMT
Received: from bda381.bisx.prod.on.blackberry (localhost.localdomain
[127.0.0.1])
by bda381.bisx.prod.on.blackberry (8.13.4 TEAMON/8.13.4) with ESMTP id
m4E0jn7T000408; Wed, 14 May 2008 00:45:49 GMT
X-rim-org-msg-ref-id: 1660532724
Message-ID: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713-@bxe033.bisx.prod.on.blackberry>
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
To: "Hisham Khartabil"
From: eburger@standardstrack.com
Date: Wed, 14 May 2008 00:45:44 +0000
MIME-Version: 1.0
Cc: simple@ietf.org
Subject: Re: [Simple] in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: eburger@standardstrack.com
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Nice to have, but useless (language issue) as well as an attack vector. If =
that information is really important, we should have codes or tokens an aut=
omoton can interpret.
------Original Message------
From: Hisham Khartabil
To: Eric Burger
Cc: simple@ietf.org
Subject: Re: [Simple] in IMDN
Sent: May 14, 2008 7:17 AM
It for the IMDN to carry extra information about the IM. For example, infor=
mation on why it was not delivered. =
=A0 =
=A0=A0
=A0=A0
=A0=A0=A0=A0=A0 34jk324j
=A0=A0=A0=A0=A0 2006-04-04T12:16:49-05:00
=A0=A0=A0=A0=A0 im:bob@example.com
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 im:bob@example.com =
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0 The IM could not be delivered due to netw=
ork failure
=A0=A0
=A0 =
On 13/05/2008, Eric Burger > wrote: Why do we have a field in an IMDN?
It cannot be for correlation, as the sender MUST have a Message-ID.
=
It cannot be for letting the user what the message is, because we are
talking about IMs here, not e-mails.
It cannot be for displaying status to the IM sender, because the IM
Recipient UA has no idea what the locale of the sender is and will
undoubtably use the wrong language and character set.
It could be used as a spam attack vector, but that would be silly of
us to build in to a protocol.
Does ANYONE object to simply taking out the field?
Does ANYONE want the field to be present?
Please respond to the list ASAP, as this document is WAY overdue.
_______________________________________________
Simple mailing list
Simple@ietf.org =
https://www.ietf.org/mailman/listinfo/simple =
=
Sent from my Verizon Wireless BlackBerry
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Tue May 13 19:39:47 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 681A73A697E;
Tue, 13 May 2008 19:39:47 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 61C463A697E
for ; Tue, 13 May 2008 19:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 cpFEjDchc2vJ for ;
Tue, 13 May 2008 19:39:43 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226])
by core3.amsl.com (Postfix) with ESMTP id 5FD183A6951
for ; Tue, 13 May 2008 19:39:43 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so3040410rvf.49
for ; Tue, 13 May 2008 19:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
bh=mXmeCcYj9t0rk2oqStSji94JM0wIjDvwUb3C0hA0aUQ=;
b=f47VYycwz2lrMTkmQz3RNewhNGLQiO8ugKRqwPmL1fCeWY3ElZPthbv4oz3nBEsyHmP3Le6rAsGCVOx2cm2A7nlbEUO7XMm1P96eoJYMo4CR7Girln37ss760mHs6WCv2BevH9UKY34+OR5/y9P2ierpCWWPKGokF63PNcDklVA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
b=lErNUEN59XL7toZoEGxjDiOwr/oH9PQGSiXEGQslSCWxsVgN2wCNEfDK/tnUVWoEU4C/dw86uPEFSiwT7GO7ErHK/YAvk+Ax4KyFisey5OEYDL4v/eU7N08uiRK40UNAI0KacMRbq6zHRc/GTAs84qnnPF9UmE+Y4FlGVE71DqQ=
Received: by 10.114.124.12 with SMTP id w12mr473615wac.210.1210732783922;
Tue, 13 May 2008 19:39:43 -0700 (PDT)
Received: by 10.114.235.10 with HTTP; Tue, 13 May 2008 19:39:43 -0700 (PDT)
Message-ID: <66cd252f0805131939t6569dab7r45d8ced20471a157@mail.gmail.com>
Date: Wed, 14 May 2008 12:39:43 +1000
From: "Hisham Khartabil"
To: eburger@standardstrack.com
In-Reply-To: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713-@bxe033.bisx.prod.on.blackberry>
MIME-Version: 1.0
References: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713-@bxe033.bisx.prod.on.blackberry>
Cc: simple@ietf.org
Subject: Re: [Simple] in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============0708618226=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
--===============0708618226==
Content-Type: multipart/alternative;
boundary="----=_Part_10117_8867763.1210732783896"
------=_Part_10117_8867763.1210732783896
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
well, its in there already and we are passes WGLC and into IESG Discusses. I
think its too late to be asking the question of requirements.
Regards,
Hisham
On 14/05/2008, eburger@standardstrack.com
wrote:
>
> Nice to have, but useless (language issue) as well as an attack vector. If
> that information is really important, we should have codes or tokens an
> automoton can interpret.
> ------Original Message------
> From: Hisham Khartabil
> To: Eric Burger
> Cc: simple@ietf.org
> Subject: Re: [Simple] in IMDN
> Sent: May 14, 2008 7:17 AM
>
> It for the IMDN to carry extra information about the IM. For example,
> information on why it was not delivered.
>
>
>
> 34jk324j
> 2006-04-04T12:16:49-05:00
> im:bob@example.com im%3Abob@example.com >
>
> im:bob@example.com im%3Abob@example.com >
>
>
>
>
>
>
>
> The IM could not be delivered due to network
> failure
>
>
>
>
> On 13/05/2008, Eric Burger eburger@standardstrack.com> > wrote: Why do we have a field in an
> IMDN?
>
> It cannot be for correlation, as the sender MUST have a Message-ID.
>
> It cannot be for letting the user what the message is, because we are
> talking about IMs here, not e-mails.
>
> It cannot be for displaying status to the IM sender, because the IM
> Recipient UA has no idea what the locale of the sender is and will
> undoubtably use the wrong language and character set.
>
> It could be used as a spam attack vector, but that would be silly of
> us to build in to a protocol.
>
> Does ANYONE object to simply taking out the field?
> Does ANYONE want the field to be present?
>
> Please respond to the list ASAP, as this document is WAY overdue.
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple <
> https://www.ietf.org/mailman/listinfo/simple>
>
>
>
> Sent from my Verizon Wireless BlackBerry
------=_Part_10117_8867763.1210732783896
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
well, its in there already and we are passes WGLC and into IESG Discusses. I think its too late to be asking the question of requirements.
Nice to have, but useless (language issue) as well as an attack vector. If that information is really important, we should have codes or tokens an automoton can interpret.
------Original Message------ From: Hisham Khartabil To: Eric Burger Cc: simple@ietf.org Subject: Re: [Simple] <note> in IMDN Sent: May 14, 2008 7:17 AM
It for the IMDN to carry extra information about the IM. For example, information on why it was not delivered.
<?xml version="1.0" encoding="UTF-8"?> <imdn xlmns="urn:ietf:params:xml:ns:imdn"> <message-id>34jk324j</message-id> <datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com <mailto:im%3Abob@example.com> </recipient-uri> <original-recipient-uri> im:bob@example.com <mailto:im%3Abob@example.com> </original-recipient-uri> <disposition>
<delivery/> </disposition> <status> <failed/> </status> <note lang="en">The IM could not be delivered due to network failure</note>
</imdn>
It cannot be for correlation, as the sender MUST have a Message-ID.
It cannot be for letting the user what the message is, because we are talking about IMs here, not e-mails.
It cannot be for displaying status to the IM sender, because the IM
Recipient UA has no idea what the locale of the sender is and will undoubtably use the wrong language and character set.
It could be used as a spam attack vector, but that would be silly of us to build in to a protocol.
Does ANYONE object to simply taking out the field? Does ANYONE want the field to be present?
------=_Part_10117_8867763.1210732783896--
--===============0708618226==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
--===============0708618226==--
From floor_vk@yahoo.com Tue May 13 19:44:01 2008
Return-Path:
X-Original-To: ietfarch-simple-archive@core3.amsl.com
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id C4BC93A68D8
for ; Tue, 13 May 2008 19:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -66.281
X-Spam-Level:
X-Spam-Status: No, score=-66.281 tagged_above=-999 required=5
tests=[AWL=2.232, BAYES_50=0.001, FH_RELAY_NODNS=1.451,
HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, 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, RCVD_IN_SORBS_DUL=0.877,
RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20,
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 NXccLOH2Xz9A
for ;
Tue, 13 May 2008 19:44:00 -0700 (PDT)
Received: from [201.34.80.7] (unknown [201.34.80.7])
by core3.amsl.com (Postfix) with ESMTP id 7D9E23A6951
for ; Tue, 13 May 2008 19:43:58 -0700 (PDT)
Received: from [201.34.80.7] by a.mx.mail.yahoo.com; Tue, 13 May 2008 23:43:59 -0300
From: "Google AdWords"
To:
Subject: Your ads in this account are not running.
Date: Tue, 13 May 2008 23:43:59 -0300
Message-ID: <01c8b553$37044980$075022c9@floor_vk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0006_01C8B553.37044980"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
This is a multi-part message in MIME format.
------=_NextPart_000_0006_01C8B553.37044980
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
----------------------------------------------------------------------------
Dear Google AdWords Customer,
We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment information.
Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.
----------------------------------------------------------------------------------------------
This message was sent from a notification-only email address that does
not accept incoming email. Please do not reply to this message.
------------------------------------------------------------------------------------------
We look forward to providing you with the most effective advertising available.
Thank you for choosing AdWords.
------=_NextPart_000_0006_01C8B553.37044980
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
-------------------------------------------------------------------------=
---------------
Dear Google AdWords Customer,
We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info=
rmation.
-------------------------------------------------------------------------=
-----------
This message was sent from a notification-only email address that does
not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------=
--
------=_NextPart_000_0006_01C8B553.37044980--
From simple-bounces@ietf.org Tue May 13 20:52:02 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F277B3A6985;
Tue, 13 May 2008 20:52:01 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 81C943A6877
for ; Tue, 13 May 2008 20:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
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 jc3iLXBuf7GP for ;
Tue, 13 May 2008 20:51:59 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id A80D23A68DA
for ; Tue, 13 May 2008 20:51:59 -0700 (PDT)
Received: from [124.17.15.2] (port=27524 helo=[172.31.13.16])
by gs19.inmotionhosting.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from )
id 1Jw81b-0002LN-C7; Tue, 13 May 2008 20:51:37 -0700
Message-Id: <77384F67-E82C-483C-B555-665BFAF02D4E@standardstrack.com>
From: Eric Burger
To: "Hisham Khartabil"
In-Reply-To: <66cd252f0805131939t6569dab7r45d8ced20471a157@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v912)
Date: Wed, 14 May 2008 11:51:37 +0800
References: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713-@bxe033.bisx.prod.on.blackberry>
<66cd252f0805131939t6569dab7r45d8ced20471a157@mail.gmail.com>
X-Mailer: Apple Mail (2.912)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: simple@ietf.org
Subject: Re: [Simple] in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Do you have text for the Security Considerations section short of
"here is a nice big attack vector that, by the way, has no protocol
use"?
On May 14, 2008, at 10:39 AM, Hisham Khartabil wrote:
> well, its in there already and we are passes WGLC and into IESG
> Discusses. I think its too late to be asking the question of
> requirements.
>
> Regards,
> Hisham
>
>
> On 14/05/2008, eburger@standardstrack.com
> wrote: Nice to have, but useless
> (language issue) as well as an attack vector. If that information is
> really important, we should have codes or tokens an automoton can
> interpret.
> ------Original Message------
> From: Hisham Khartabil
> To: Eric Burger
> Cc: simple@ietf.org
> Subject: Re: [Simple] in IMDN
> Sent: May 14, 2008 7:17 AM
>
> It for the IMDN to carry extra information about the IM. For
> example, information on why it was not delivered.
>
>
>
> 34jk324j
> 2006-04-04T12:16:49-05:00
> im:bob@example.com %3Abob@example.com>
>
> im:bob@example.com
>
>
>
>
>
>
>
> The IM could not be delivered due to network
> failure
>
>
>
>
> On 13/05/2008, Eric Burger > > wrote: Why do we have a field in an IMDN?
>
> It cannot be for correlation, as the sender MUST have a Message-ID.
>
> It cannot be for letting the user what the message is, because we are
> talking about IMs here, not e-mails.
>
> It cannot be for displaying status to the IM sender, because the IM
> Recipient UA has no idea what the locale of the sender is and will
> undoubtably use the wrong language and character set.
>
> It could be used as a spam attack vector, but that would be silly of
> us to build in to a protocol.
>
> Does ANYONE object to simply taking out the field?
> Does ANYONE want the field to be present?
>
> Please respond to the list ASAP, as this document is WAY overdue.
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple >
>
>
>
> Sent from my Verizon Wireless BlackBerry
>
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Tue May 13 21:21:22 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0E92F3A6877;
Tue, 13 May 2008 21:21:22 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id AFF743A6877;
Tue, 13 May 2008 21:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
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 KEsDGcLDWX85; Tue, 13 May 2008 21:21:18 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189])
by core3.amsl.com (Postfix) with ESMTP id 7F5B03A67D4;
Tue, 13 May 2008 21:21:18 -0700 (PDT)
Received: from [124.17.15.2] (port=36151 helo=[172.31.13.16])
by gs19.inmotionhosting.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from )
id 1Jw8TP-0006D4-4J; Tue, 13 May 2008 21:20:19 -0700
Message-Id:
From: Eric Burger
To: Eric Rescorla
In-Reply-To: <20080503211234.0377B5081A@romeo.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v912)
Date: Wed, 14 May 2008 12:20:21 +0800
References: <20080503211234.0377B5081A@romeo.rtfm.com>
X-Mailer: Apple Mail (2.912)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: secdir@mit.edu, ietf@ietf.org, simple@ietf.org, iesg@ietf.org
Subject: Re: [Simple] Re-review of draft-ietf-simple-imdn
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Inline
On May 4, 2008, at 5:12 AM, Eric Rescorla wrote:
> I originally reviewed version -06 of this document
> (2008-02-8). Examining the diff, it does not appear to me that any of
> my comments from my previous review. Looking back in my mail folder, I
> don't see any reasponses from the authors telling me my review was
> wrong, so I'm retransmitting it here.
>
> -Ekr
>
> $Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr
> Exp $
>
> This document describes a mechanism for IM senders to request status
> notifications for their IMs. The sender attaches a header specifying
> the status conditions he wants to be notified of and intermediaries
> and the receiving UA notify the sender (or someone else of his choice)
> subject to policy constraints.
>
> One thing I'm not clear on is how the recipient determines where to
> send the IMDN. Are they supposed to read the "From" field? One thing
> that I don't get is how the IMDN-Route header interacts here.
> It looks to me like this gets stuffed in the "To" in the IMDN.
You are right - we go on and on about IMDN-Record-Route, but we never
explicitly say what to do if there is no IMDN-Record-Route. How about
the following text, inserted after the IMDN-Record-Route handling
paragraph:
If there is no IMDN-Record-Route header field, the IM Recipient
MUST send the IMDN to the URI in the From header field.
> What happens if someone puts an IMDN-Record-Route that points
> to an IMDN-ignorant UA?
We need to make it clear that an intermediary can only intermediate on
its own behalf.
How about the following text change in the Intermediary Behaviour
section:
OLD
An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field and populating it with
its own address.
NEW
An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field. The value of this
field MUST be the intermediary's own address.
I was mulling over whether this introduces a security issue.
Specifically, what if a malicious intermediary wants to perform a DDoS
attack on an unsuspecting UA? The intermediary could spew a bunch of
messages towards other UAs, asking them to send IMDNs to DDoS target
by setting the topmost Record-Route to the target machine. The good
news is this takes a similar amount of resources as that intermediary
attacking the target directly. The bad news is the IMDN-Record-Route
mechanism provides a mechanism for the malicious node to hide its
identity from the target. The same issue arises if the node simply
puts in the target node as the From field of the IM and requests an
IMDN. The only trace would be server logs, which could identify the
malicious node as the source of the bogus IMDN requests.
How about we add the following to the "threats in the IMDN system"
list in the Security Considerations section:
A malicious intermediary or node attempts to flood a target
node with IMDNs by inserting the target's address in the From
field or IMDN-Record-Route field
And this text towards the end of the section:
One way to address the potential for a malicious node to use
the IMDN system to anonomize attacks is to log all IMDN
requests on the IM Recipient User Agent. This allows for tracking
of attacks, if only after they occur. Note this also puts a
burden on
the IM Recipient User Agent host. Limited User Agents may not
be able to preserve much of a log.
> Overall, this document seems pretty well written and clearly lays out
> the security issues.
>
> That said, I'm concerned about the bounce/reflection threats discussed
> in S 14 (where the sender asks for notification to a third party
> victim). I'm particularly concerned about the "note" field, since a
> natural implementation seems to be to include an excerpt from the
> message you're acknowledging. This draft identifies the threat but
> doesn't specify any mechanism for ameliorating them. I think some
> suggested mechanisms would be appoprirate here, or at least some
> analysis of what the potential mechanisms were and why they would or
> would not work.
The field is stupid IMHO. I'm taking that to the list. Thanks
for "noting" it, and I am embarrassed it is in the draft at all.
> Other comments: I would avoid the term "non-repudiation" if at all
> possible in S 5.3 and later. It's just so overloaded now that it's
> hard to know what it means.
Fixed
> S 6.5. A little more explanation of why IMDN-Record-Route is useful
> would help.
Done
> S 7.1.1.1. Why does Message-ID need any randomness at all as opposed
> to uniqueness? And if it needs randomness, why is 32 enough?
The randomness property makes it more difficult for malicious nodes
guessing Message-IDs and thus being able to pass IMDNs through
filtering mechanisms.
IYHO, is 32-bits enough? You're the expert; I'm just guessing!
> S 7.1.3. Note that you can pack the state into the messageid if
> you're willing to make large message ids and hte stte is small.
Message-ID could be used for tracking in addition to IMDN, so
combining the two would not be a good thing.
> S 11.1
>
> An IMDN Payload is an XML document [6] that MUST be well formed and
> MUST be valid according to schemas, including extension schemas,
> available to the validater and applicable to the XML document. The
> IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
> UTF-8.
>
> Is this a requirement that the receiver validate the XML?
On the one hand, I suppose it is. On the other hand, that is totally
unenforceable. Can this one slide under the radar?
> S 12.1.1. Why can't anonymous senders request notifications?
Where would one send the IMDN to?
> S 14.3. See above comemnts about nonrepudiation
Fixed.
> -Ekr
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Tue May 13 21:38:44 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4ECF73A68D5;
Tue, 13 May 2008 21:38:44 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 704693A6784
for ; Tue, 13 May 2008 21:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Xjzt2giccLkO for ;
Tue, 13 May 2008 21:38:38 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251])
by core3.amsl.com (Postfix) with ESMTP id E505E3A68D5
for ; Tue, 13 May 2008 21:38:37 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id d18so2293776and.122
for ; Tue, 13 May 2008 21:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
bh=ZrSQhZHqwWy5/3CY+Y6CgnlCl6ZG8GvLKg+BjNfx2FE=;
b=QUaCfxHRLUtJ8AJeox5tz01HrbKroi3onbQiMZ3v1fMZLOL4fDBdh8LrpSQYBGbLa4fdF7hHXaNrFvNojUpC+rNdwoOwrSkDKG3EItNspOjQirV5IGv6GH0M/7ZJGcqVdvrwHixgl/j954JhiBPxOziuCb0sRTnnLTtKS79GVns=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
b=vzVYkgPqoiijFo19ZHeI+hsaq2H4LyVngAD8aklBpFKHqt72/qxueXEV+iBCdQIu+pJpsMgrkLIZEMqS3QupvCKoPOniuZ6awVg+jLSJs+/aDuKJm4pmvXJ9Uv97yHqdZtmaRZiRsuQlcDEzshzRW/JLZZ6z7rM3aTjAMgVPAl0=
Received: by 10.115.18.3 with SMTP id v3mr593860wai.180.1210739917503;
Tue, 13 May 2008 21:38:37 -0700 (PDT)
Received: by 10.114.235.10 with HTTP; Tue, 13 May 2008 21:38:37 -0700 (PDT)
Message-ID: <66cd252f0805132138m23aa3f42kf01ce0dcb7c42181@mail.gmail.com>
Date: Wed, 14 May 2008 14:38:37 +1000
From: "Hisham Khartabil"
To: "Eric Burger"
In-Reply-To: <77384F67-E82C-483C-B555-665BFAF02D4E@standardstrack.com>
MIME-Version: 1.0
References: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713-@bxe033.bisx.prod.on.blackberry>
<66cd252f0805131939t6569dab7r45d8ced20471a157@mail.gmail.com>
<77384F67-E82C-483C-B555-665BFAF02D4E@standardstrack.com>
Cc: simple@ietf.org
Subject: Re: [Simple] in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============2042359952=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
--===============2042359952==
Content-Type: multipart/alternative;
boundary="----=_Part_10450_22343973.1210739917491"
------=_Part_10450_22343973.1210739917491
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Can you explain how it is an attack vector?
On 14/05/2008, Eric Burger wrote:
>
> Do you have text for the Security Considerations section short of "here is
> a nice big attack vector that, by the way, has no protocol use"?
>
> On May 14, 2008, at 10:39 AM, Hisham Khartabil wrote:
>
> well, its in there already and we are passes WGLC and into IESG Discusses.
> > I think its too late to be asking the question of requirements.
> >
> > Regards,
> > Hisham
> >
> >
> > On 14/05/2008, eburger@standardstrack.com
> > wrote: Nice to have, but useless (language issue) as well as an attack
> > vector. If that information is really important, we should have codes or
> > tokens an automoton can interpret.
> > ------Original Message------
> > From: Hisham Khartabil
> > To: Eric Burger
> > Cc: simple@ietf.org
> > Subject: Re: [Simple] in IMDN
> > Sent: May 14, 2008 7:17 AM
> >
> > It for the IMDN to carry extra information about the IM. For example,
> > information on why it was not delivered.
> >
> >
> >
> > 34jk324j
> > 2006-04-04T12:16:49-05:00
> > im:bob@example.com > im%3Abob@example.com>
> >
> > im:bob@example.com > im%3Abob@example.com >
> >
> >
> >
> >
> >
> >
> >
> > The IM could not be delivered due to network
> > failure
> >
> >
> >
> >
> > On 13/05/2008, Eric Burger > eburger@standardstrack.com> > wrote: Why do we have a field in an
> > IMDN?
> >
> > It cannot be for correlation, as the sender MUST have a Message-ID.
> >
> > It cannot be for letting the user what the message is, because we are
> > talking about IMs here, not e-mails.
> >
> > It cannot be for displaying status to the IM sender, because the IM
> > Recipient UA has no idea what the locale of the sender is and will
> > undoubtably use the wrong language and character set.
> >
> > It could be used as a spam attack vector, but that would be silly of
> > us to build in to a protocol.
> >
> > Does ANYONE object to simply taking out the field?
> > Does ANYONE want the field to be present?
> >
> > Please respond to the list ASAP, as this document is WAY overdue.
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www.ietf.org/mailman/listinfo/simple <
> > https://www.ietf.org/mailman/listinfo/simple>
> >
> >
> >
> > Sent from my Verizon Wireless BlackBerry
> >
> >
>
------=_Part_10450_22343973.1210739917491
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Can you explain how it is an attack vector?
Do you have text for the Security Considerations section short of "here is a nice big attack vector that, by the way, has no protocol use"?
On May 14, 2008, at 10:39 AM, Hisham Khartabil wrote:
well, its in there already and we are passes WGLC and into IESG Discusses. I think its too late to be asking the question of requirements.
Regards, Hisham
On 14/05/2008, eburger@standardstrack.com <eburger@standardstrack.com> wrote: Nice to have, but useless (language issue) as well as an attack vector. If that information is really important, we should have codes or tokens an automoton can interpret.
------Original Message------ From: Hisham Khartabil To: Eric Burger Cc: simple@ietf.org Subject: Re: [Simple] <note> in IMDN
Sent: May 14, 2008 7:17 AM
It for the IMDN to carry extra information about the IM. For example, information on why it was not delivered.
<?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn"> <message-id>34jk324j</message-id> <datetime>2006-04-04T12:16:49-05:00</datetime> <recipient-uri>im:bob@example.com <mailto:im%3Abob@example.com> </recipient-uri>
<original-recipient-uri> im:bob@example.com <mailto:im%3Abob@example.com>
</original-recipient-uri> <disposition> <delivery/> </disposition> <status> <failed/> </status> <note lang="en">The IM could not be delivered due to network failure</note>
</imdn>
It cannot be for correlation, as the sender MUST have a Message-ID.
It cannot be for letting the user what the message is, because we are talking about IMs here, not e-mails.
It cannot be for displaying status to the IM sender, because the IM
Recipient UA has no idea what the locale of the sender is and will undoubtably use the wrong language and character set.
It could be used as a spam attack vector, but that would be silly of us to build in to a protocol.
Does ANYONE object to simply taking out the field? Does ANYONE want the field to be present?
------=_Part_10450_22343973.1210739917491--
--===============2042359952==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
--===============2042359952==--
From simple-bounces@ietf.org Wed May 14 00:45:20 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 70FED3A695B;
Wed, 14 May 2008 00:45:20 -0700 (PDT)
X-Original-To: simple@ietf.org
Delivered-To: simple@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0)
id 77A0C3A682A; Wed, 14 May 2008 00:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080514074501.77A0C3A682A@core3.amsl.com>
Date: Wed, 14 May 2008 00:45:01 -0700 (PDT)
Cc: simple@ietf.org
Subject: [Simple] I-D Action:draft-ietf-simple-prescaps-ext-10.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.
Title : Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)
Author(s) : M. Lonnfors, K. Kiss
Filename : draft-ietf-simple-prescaps-ext-10.txt
Pages : 30
Date : 2008-05-14
Presence Information Data Format (PIDF) defines a common presence
data format for Common Profile for Presence (CPP) compliant Presence
protocols. This memo defines an extension to represent SIP User
Agent capabilities in the Presence Information Document Format (PIDF)
compliant presence documents.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-10.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Message/External-body;
name="draft-ietf-simple-prescaps-ext-10.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-05-14003217.I-D@ietf.org>
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
--NextPart--
From simple-bounces@ietf.org Wed May 14 09:10:56 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 30A263A6837;
Wed, 14 May 2008 09:10:54 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9E65E3A682A;
Wed, 14 May 2008 09:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.007
X-Spam-Level:
X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=0.992,
BAYES_00=-2.599, J_CHICKENPOX_16=0.6]
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 cHCSyq+zaFcJ; Wed, 14 May 2008 09:09:53 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189])
by core3.amsl.com (Postfix) with ESMTP id D794E3A68BB;
Wed, 14 May 2008 09:09:50 -0700 (PDT)
Received: from [124.17.15.2] (port=32239 helo=[172.31.13.11])
by gs19.inmotionhosting.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from )
id 1JwJVE-0004RL-Qc; Wed, 14 May 2008 09:06:53 -0700
Message-Id: <7B1461BA-48CB-419A-A573-90763BDEAF3C@standardstrack.com>
From: Eric Burger
To: iesg@ietf.org
Mime-Version: 1.0 (Apple Message framework v912)
Date: Thu, 15 May 2008 00:06:50 +0800
X-Mailer: Apple Mail (2.912)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: simple@ietf.org
Subject: [Simple] DISCUSSes on IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
A thousand pardons. Missing ekr's comments should have warned me that
we missed other comments. I only just now reviewed the DISCUSSes.
Please have pity for this mistake.
There have been so many DISCUSSes and comments, specifically GEN-ART
and SECDIR, that a new draft will be forthcoming.
> DISCUSSES AND COMMENTS:
> ======================
> Lars Eggert: Comment [2008-05-08]: Section 5.3., paragraph 2: > In
> addition to text, some IMs may contain audio, video, and still >
> images. Therefore, the state "read" includes playing the audio or >
> video file to the user. Does it indicate the start of playback, or
> when playback has concluded? (Probably the former, but it might be
> good to be explicit in the text.)
Start of playback. Fixed.
> Section 5.3., paragraph 3: > Since there is no positive
> acknowledgement from the user, one cannot > determine _a priori_ the
> user actually read the IM. Thus, one cannot > use the protocol
> described here as a non-repudiation service. That restriction - that
> getting a "read" IMDN doesn't actually mean that the recipient is
> guaranteed to have read the IM - seems important enough to describe
> more prominently, e.g., in the introduction. "Read" is maybe also a
> bit inaccurate, maybe "rendered" would be a better term, i.e., the
> IM has been rendered to the user, which is about as much as a
> program can guarantee it did. It's probably too late to make this
> wording change, but an explanation can still be added. (Nit: I don't
> understand what "a priori" is supposed to express in this sentence.)
I can take a hint. You are the third person to question a'priori. It
comes out.
NEW
In addition to text, some IMs may contain audio, video, and still
images. Therefore, the state "read" includes the start of rendering
the audio or video file to the user. Note that the term "read" is a
token indicating the User Agent began to render or display the IM.
> Section 7.1.1.1., paragraph 1: > The Message-ID field is populated >
> with a value that is unique with at least 32 bits of randomness.
> Nit: It's not unique, it's _statistically_ unique.
Fixed, but this will depend on ekr's analysis of the new wording
(posted to IETF and SIMPLE lists).
> Section 7.1.3., paragraph 2: > Once an IM Sender sends an IM
> containing an IMDN request, it MAY > preserve the IM context,
> principally the Message-ID, and other user- > identifiable
> information such as the IM subject or content, and date > and time
> it was sent. Isn't a MAY a bit weak? Requesting IMDNs when I'm not
> going to be able to correlate them to specific sent messages seems
> to be pretty pointless.
I agree, but the consensus of the work group was that mandating the IM
Sender to keep this state will not be practical for devices with
limited or volatile memory. That is also why we keep the sending time
so the sender might have a clue what IM this IMDN is in reference to.
> Section 12.1.1., paragraph 4: > An IM Recipient can ignore such
> request > if the IM Sender is anonymous. Nit: s/can/MAY/
Fixed.
> Section 13., paragraph 1: > MSRP already provides a built-in
> mechanism to supply positive and > negative delivery reports.
> Reference to MSRP missing.
Fixed.
> Section 14., paragraph 1: > IMDNs provide a fine-grained view of the
> activity of the IM Recipient > and thus deserves particularly
> careful confidentiality protection so > that only the intended
> recipient of the IMDN will receive the IMDN. > In most cases, the
> intended recipient of the IMDN is the IM Sender. When the IMDN
> recipient isn't the sender but instead the IMDN is addressed to
> multiple recipients, an amplification attack can be performed. Is
> this a new threat with IMDNs or is this already being discussed for
> the base IM transport?
Not an issue, as one cannot have multiple addresses, UNLESS one
inserts a IMDN-Route that is a list server.
> Pasi Eronen: Discuss [2008-05-08]:
> Process note: Eric Rescorla's SecDir review needs a response.
Done.
> Note a single one of the XML examples is actually valid according to
> the RelaxNG schema (they have things like misspelled attribute
> names, missing required elements, etc.).
Will fix
> The document needs a better explanation of why (the rather ugly)
> IMDN-Record-Route/IMDN-Route mechanism is needed (especially since
> there's no similar mechanism for sending normal IM replies).
Personally, I think it's wholly unnecessary, but it appears to be work
group consensus. I will defer to the chairs on this one.
> The RelaxNG schema has an "Extension" element, but there's no text
> describing how the extension mechanism works. Also, the statement in
> 15.3 saying "Extensions MUST be standards track documents" isn't
> very clear.
> Sections 15.2 and 15.3 attempt to register the same URI for two
> purposes; please clarify.
Fixed in EKR response
> Section 15.4 says "Additional values may be defined by standards
> track RFCs that update or obsolete RFC XXXX (Specification
> Required)"; please make this clearer.
Standards Action. Fixed.
> From Eric Rescorla's SecDir review: [snip]
Dealt with in a separate e-mail.
> Chris Newman: Discuss [2008-05-06]: 1. I could not find a response
> to Frank Ellermann's last call comments on "Wed, 16 Jan 2008
> 12:17:48 +0100" to the IETF mailing list. I do not consider it
> acceptable to simply ignore last call comments. Please cc me on any
> correspondence to Frank and the ietf list on this issue. Most of the
> issues he raised I consider discuss-level issues.
Here are Frank's issues:
> | It is strongly RECOMMENDED that the IM Recipient obtain
> | the user's consent before sending an IMDN. Circumstances
> | where the IM Recipient does not ask for the user's consent
> | include IM systems that, for regulatory reasons, are
> | required to issue an IMDN, such as in the health care
> | field or financial community.
> IMO nothing less than a MUST is acceptable, no matter what RFC 3798
says. Assuming that anybody allows MDNs without explicit permission, I
don't.
Unfortunately, this was (a) something with strong work group
consensus, due to the factors enumerated above and (b) something
wholly unenforceable at the protocol level. What is the point of
making something a MUST that never sees the light of day?
> | Electronic Mail [10] deals with this situation with Message
> | Delivery Notifications [11]. After the recipient views the
> | message, her mail user agent generates a Message Delivery
> | Notification, or MDN.
> Dubious. E-mail *offers* this (in RFC 3798), but MUAs doing it
without explicit permission would be considered harmful.
Correct on the assertion that e-mail offers, not deals with the
situation. However, again mandating that a MUA *never* automatically
generates an MDN with out explicit permission is pure wishful thinking.
How about:
Electronic Mail offers a solution to this need with Message
Delivery Notifications.
> | unique with at least 32 bits of randomness
> If it's random it isn't necessarily unique, or I miss a clue.
You are again correct. Already fixed.
> | Message-ID = "Message-ID" ": " Token
> What's a ? The 34jk324j example isn't supposed to be
"worldwide unique forever" as in all "Message-ID" definitions since
1994, or is it ? Maybe the draft should say "Token" where it says
"Message-ID", and of course define the .
Will fix.
> 2. The "read" status is misleading for the reasons 3798 describes.
> Why did you choose not to use "displayed" as defined in RFC 3798?
> Having semantically misleading statements in protocols is simply not
> good design and I'd like a justification for doing something
> different from the previous IETF draft standard in this area.
Historic drivel from the merge of the two IMDN root documents. I am
willing to change all of the "read"s to "diplayed"s. However, I will
leave that decision to the chairs to determine if we should go to the
work group to ask if the 4-byte string that happens to decode to 'r'
'e' 'a' 'd' in ASCII should be changed to something meaningful and not
misleading.
> 3. This appears to combine DSN (RFC 3464) and MDN (RFC 3798)
> features into one protocol. As they are related and the primary
> reason for the specification split is historic, I think combining
> the features is a good thing. But there are semantic differences
> between the two protocols that are both useful and important. In
> particular, when a client requests a DSN it is guaranteed to get a
> response by RFC 3461, while responses to MDNs are optional. This is
> a very useful property although it is only possible if the "relayed"
> action from RFC 3464 is included in the model and generated in
> response to a request for delivery success status. Why did you
> choose not to provide this feature of DSNs? If the WG considered
> this and made a willful decision, I'm not going to insist on a
> change, but I at least want to understand why the IETF suite of
> standards will be inconsistent on such an important semantic.
Willful decision of the WG, over the objection of this editor. The
editor humbly complied, as while it is painful, it is not harmful.
> 4. The decision to mix transitive routing information (IMDN-Record-
> Route, IMDN-Route) into the IMDN content itself is bad design,
> especially when that information is to be removed by intermediaries.
> That makes any sort of content based signature impossible, and such
> mechanisms are likely to become an important part of the necessary
> reputation systems as the volume of IM spam increases over time.
> Deliberately designing a signature-hostile format when it is so
> likely signatures will be critical to long term use of the protocol
> is something that will require extensive justification to convince
> me it's acceptable quality for an IETF standard.
This editor agrees. The claim is this is the WG consensus.
> 5. I could find no record of the IETF-types review in the IETF-types
> archives: http://www.alvestrand.no/pipermail/ietf-types/2007-February/thread.html
> Can someone please provide a copy of the review request as received
> from the ietf-types list expander? I want to make sure the message
> was actually distributed to the list and not lost in transit.
I don't see it, either. I would offer we cycle through these comments
before resending.
> 6. RFC 3862 has an example message with the same subject in two
> different languages. How does the element handle this in
> the IMDN? Is a lang parameter included on the subject typically?
Can only be one, unless we are in to machine translation. How about:
NEW
The element is optional. If present it MUST cary the
text and, if present, language attribute, that was in the Subject
header field, if any. This allows for a human level correlation
between an IM and an IMDN.
> 7. When using a formal schema language, it is important to say in
> the specification how it relates normatively to this document and
> future extensions. Is the schema a normative definition of the
> current format? Is the schema a normative definition constraining
> all future extensions of the format? If the answer to the latter
> question is "yes", then I recommend you read chapter 12 of "Relax
> NG" by Eric van der Vlist and revise your Relax NG schema
> accordingly or you will be painting yourself in a box. Briefly: you
> should use the interleave pattern, I'm not sure your 'anyIMDI' is
> correct (see "anything" in the book) and if you put the addition of
> 'anyIMDI' in a separate define from the list of pre-defined elements
> that will simplify extending the schema. BTW, thanks for using
> RelaxNG as it's much simpler to read and review than W3C schema.
Will fix.
> 8. Section 15.4 says both "Specification Required" and "IETF
> Standards track" (implying it's a "standards action" registry). What
> is the intended registry type?
Standards Action. Fixed
> 9. Have all the questions IANA asked been resolved? Note: I have
> deliberately not reviewed the security considerations section
> assuming the security directoriate and ADs have that covered.
Yes.
> Tim Polk: Discuss [2008-05-06]:
> This is a process discuss. Eric Rescorla's secdir review (first
> posted February 8 and re-posted May 3) has never received a
> response. I consider the issues he raised on bounce/reflection
> threats and determining where to send the IMDN to be blocking. (Is
> the latter addressed in the last sentence of 12.1.3.1?)
There is a lively debate between the editors and no one else on the
SIMPLE list on this issue. See the thread starting with:
http://www.ietf.org/mail-archive/web/simple/current/msg07846.html
> I also support avoiding the term non-repudiation unless it is
> defined in this document for this context.
Fixed.
> Magnus Westerlund: Discuss [2008-05-06]:
> Section 10: The ABNF is not complete and lacks references to some
> definitions. To my check even after including the ABNF from RFC 3862
> the followings are undefined: COMMA SEMI generic-param Then there is
> a typo in the the rule: notify-req = ("negative-delivery" /
> "positive-delivery" / "processing" / "read" / Token) *(SEMI disp-
> notif-params) disp-notif-params is missing a "y"
Will fix.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Wed May 14 09:27:33 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 48C1A28C0F5;
Wed, 14 May 2008 09:27:33 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E47673A68A7;
Wed, 14 May 2008 09:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level:
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150,
BAYES_00=-2.599]
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 3KvGywOv1zXM; Wed, 14 May 2008 09:27:28 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189])
by core3.amsl.com (Postfix) with ESMTP id ADD5F3A67F7;
Wed, 14 May 2008 09:27:28 -0700 (PDT)
Received: from [124.17.15.2] (port=45892 helo=[172.31.13.11])
by gs19.inmotionhosting.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from )
id 1JwJoU-00082C-Ob; Wed, 14 May 2008 09:26:50 -0700
Message-Id: <28AB2CB7-DE19-42B0-906C-2D900FEDFB1A@standardstrack.com>
From: Eric Burger
To: Eric Rescorla
In-Reply-To: <20080514154217.28E375081A@romeo.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v912)
Date: Thu, 15 May 2008 00:25:38 +0800
References: <20080503211234.0377B5081A@romeo.rtfm.com>
<20080514154217.28E375081A@romeo.rtfm.com>
X-Mailer: Apple Mail (2.912)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: secdir@mit.edu, ietf@ietf.org, simple@ietf.org, iesg@ietf.org
Subject: [Simple] Randomness of Message-ID in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Thanks for your very, very quick review! On the one open item for
discussion, Message-ID, I would offer (1) it is not a do-or-die
situation but that (2) using a cryptographically secure random number
generator. achieves the same result with better properties. Again, I
will defer back to you: I know the work group will push back strong if
a cryptographically secure random number generator is a resource hog.
Are there memory / CPU efficient cryptographically secure random
number generators? Should we give guidance to the range of numbers
(i.e., 32-bits, 512-bits, 6 digits, etc.)?
On May 14, 2008, at 11:42 PM, Eric Rescorla wrote:
> At Wed, 14 May 2008 12:20:21 +0800,
> Eric Burger wrote:
>>
>> Inline
>>
>> On May 4, 2008, at 5:12 AM, Eric Rescorla wrote:
[snip]
>>> S 7.1.1.1. Why does Message-ID need any randomness at all as
>>> opposed
>>> to uniqueness? And if it needs randomness, why is 32 enough?
>>
>> The randomness property makes it more difficult for malicious nodes
>> guessing Message-IDs and thus being able to pass IMDNs through
>> filtering mechanisms.
>>
>> IYHO, is 32-bits enough? You're the expert; I'm just guessing!
>
> So, unsurprisingly, it depends.
>
> Is your mental model that you have a list of n valid message-ids
> "outstanding" at once and you want the probability of an attacker
> guessing one to be sufficiently small? With a 32-bit space,
> the chance is n/2^32. So, if you're just treating this as a
> sort of spam filter, then it's probably fine. But if a single
> bad message getting through is fatal, then, no, it's not.
>
> The other thing I would say is that if you want ids to be
> unguessable, then you probably want to say that they should
> be generated with a cryptographically secure random number
> generator. There are lots of PRNGs that produce uniform distributions
> but that are predictable and that won't do here, right?
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Wed May 14 16:03:06 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E5A863A687B;
Wed, 14 May 2008 16:03:04 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4D2AB3A687B;
Wed, 14 May 2008 16:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.592
X-Spam-Level:
X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=1.007,
BAYES_00=-2.599]
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 n9a1Z0zt0cWr; Wed, 14 May 2008 16:01:54 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189])
by core3.amsl.com (Postfix) with ESMTP id 1A4993A6811;
Wed, 14 May 2008 16:01:54 -0700 (PDT)
Received: from [124.17.15.2] (port=47944 helo=[172.31.13.19])
by gs19.inmotionhosting.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from )
id 1JwPxJ-0002pi-5a; Wed, 14 May 2008 16:00:21 -0700
Message-Id:
From: Eric Burger
To: Eric Rescorla ,
Hisham Khartabil
In-Reply-To: <20080514172556.2819F5081A@romeo.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v912)
Date: Thu, 15 May 2008 07:00:20 +0800
References: <20080503211234.0377B5081A@romeo.rtfm.com>
<20080514154217.28E375081A@romeo.rtfm.com>
<28AB2CB7-DE19-42B0-906C-2D900FEDFB1A@standardstrack.com>
<20080514172556.2819F5081A@romeo.rtfm.com>
X-Mailer: Apple Mail (2.912)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: secdir@mit.edu, ietf@ietf.org, simple@ietf.org, iesg@ietf.org
Subject: Re: [Simple] Randomness of Message-ID in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
I think the proposed wording is excellent. Unless there is objection
(PLEASE take it to the SIMPLE list if one does, or wish to +1 it), I
would offer we use this language exactly.
On May 15, 2008, at 1:25 AM, Eric Rescorla wrote:
> At Thu, 15 May 2008 00:25:38 +0800,
> Eric Burger wrote:
>> Thanks for your very, very quick review! On the one open item for
>> discussion, Message-ID, I would offer (1) it is not a do-or-die
>> situation but that (2) using a cryptographically secure random number
>> generator. achieves the same result with better properties. Again, I
>> will defer back to you: I know the work group will push back strong
>> if
>> a cryptographically secure random number generator is a resource hog.
>>
>> Are there memory / CPU efficient cryptographically secure random
>> number generators?
>
> Yes. For instance, the NIST SP 800-90 PRNG requires order
> 256-512 bits of internal state and two hash operations for
> every hash-sized (160-512 bits) chunk of output. I would
> just use OpenSSL's cryptographically secure PRNG myself :)
>
>
>> Should we give guidance to the range of numbers
>> (i.e., 32-bits, 512-bits, 6 digits, etc.)?
>
> As I understand the situation, the sender the only person who has
> to rely on the uniqueness of this header, right?
>
>
> I would suggest instead of recommending a given number you explain
> what the issues are and why this has to be unpredictable. Perhaps
> something like this:
>
> Because the Message-ID is used by the sender to correlate IMDNs with
> their respective IMs, the Message-ID MUST be selected so that:
>
> (1) There is a minimal chance of any two Message-IDs accidentally
> colliding within the time period within which an IMDN might be
> received.
>
> (2) It is prohibitive for an attacker who has seen one or more valid
> Message-IDs to generate additional valid Message-IDs.
>
> The first requirement is a correctness requirement to ensure correct
> matching. The second requirement prevents off-path attackers from
> forging IMDNs. In order to meet both of these requirements, it is
> RECOMMENDED that Message-IDs be generated using a cryptographically
> secure pseudorandom number generator (see [RFC 4086] and contain at
> least 64 bits of randomness, thus reducing the chance of a
> successful guessing attack to n/2^64, where n is the number of
> outstanding valid messages. Another potential approach is to combine
> a sequence number (providing uniqueness) with a cryptographic MAC
> for unforgeability.
>
> Cheers,
> -Ekr
>
>
>
>
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Wed May 14 16:23:19 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B18623A6A2B;
Wed, 14 May 2008 16:23:19 -0700 (PDT)
X-Original-To: simple@ietf.org
Delivered-To: simple@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30)
id 3E7903A6840; Wed, 14 May 2008 16:23:15 -0700 (PDT)
X-idtracker: yes
From: The IESG
To: IETF-Announce
Message-Id: <20080514232315.3E7903A6840@core3.amsl.com>
Date: Wed, 14 May 2008 16:23:15 -0700 (PDT)
Cc: simple chair ,
Internet Architecture Board ,
simple mailing list ,
RFC Editor
Subject: [Simple] Protocol Action: 'Session Initiation Protocol (SIP) User
Agent Capability Extension to Presence Information Data Format (PIDF)' to
Proposed Standard
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
The IESG has approved the following document:
- 'Session Initiation Protocol (SIP) User Agent Capability Extension to
Presence Information Data Format (PIDF) '
as a Proposed Standard
This document is the product of the SIP for Instant Messaging and
Presence Leveraging Extensions Working Group.
The IESG contact persons are Jon Peterson and Cullen Jennings.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-10.txt
Technical Summary
This memo introduces a SIP specific extension mechanism to the
Presence Information Document Format to represent SIP User Agent
capabilities using the SIP feature tags defined in RFC3840. With
this extension, presence applications based on SIP can express richer
and more usable presence data compared to the baseline PIDF.
Working Group Summary
This document reflects the consensus of the SIMPLE working group.
Protocol Quality
This document was reviewed for the IESG by Jon Peterson. Robert Sparks is
the document shepherd. Gen-ART review was provided by Christian Vogt.
Note to RFC Editor
References:
Please change reference [12] to the following:
[12] Camarillo, G., "Internet Assigned Numbers Authority (IANA)
Registration of the Message Media Feature Tag", RFC 4569,
July 2006.
Also, please move reference [12] to the Informational References section
of the document.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simple-bounces@ietf.org Fri May 16 15:24:30 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id EACA73A6908;
Fri, 16 May 2008 15:24:30 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F1FAD3A6908;
Fri, 16 May 2008 15:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
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 moBl66Twwttx; Fri, 16 May 2008 15:24:28 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189])
by core3.amsl.com (Postfix) with ESMTP id 163F33A68A0;
Fri, 16 May 2008 15:24:28 -0700 (PDT)
Received: from [75.68.119.237] (port=63258 helo=[192.168.15.100])
by gs19.inmotionhosting.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from )
id 1Jx8Lc-0007tF-Vm; Fri, 16 May 2008 15:24:21 -0700
Message-Id: <68508BD2-FD7B-49A5-BB23-770F15A0FDC5@standardstrack.com>
From: Eric Burger
To: Frank Ellermann
In-Reply-To: <20080515185334.6BA8F5081A@romeo.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 16 May 2008 18:24:19 -0400
References: <20080503211234.0377B5081A@romeo.rtfm.com>
<20080514154217.28E375081A@romeo.rtfm.com>
<28AB2CB7-DE19-42B0-906C-2D900FEDFB1A@standardstrack.com>
<20080514172556.2819F5081A@romeo.rtfm.com>
<20080515185334.6BA8F5081A@romeo.rtfm.com>
X-Mailer: Apple Mail (2.919.2)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: ietf@ietf.org, simple@ietf.org
Subject: Re: [Simple] Randomness of Message-ID in IMDN
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
Please piss on me, not the other Eric. All he was doing was reviewing
the draft. It's not his fault. Please don't punish him for doing good.
It is my fault that I did not copy the response to your comments
directly to you. The message is here:
http://www.ietf.org/mail-archive/web/simple/current/msg07855.html
You are absolutely correct: Message-ID *is* supposed to be like RFC
2822 Message-ID, which means that it is supposed to be globally
unique, which means the text is under specified and I need to fix
that. Thanks for catching that one.
On May 15, 2008, at 2:53 PM, Eric Rescorla wrote:
> At Thu, 15 May 2008 18:37:51 +0200,
> Frank Ellermann wrote:
>>
>> Eric Rescorla wrote:
>>
>>> As I understand the situation, the sender the only person
>>> who has to rely on the uniqueness of this header, right?
>>
>> Hi, I have not the faintest idea what you are talking about,
>> but if it is in any way related to the 2822upd concept of
>> a Message-ID "worldwide unique forever" is no nonsense as
>> soon as a Message-ID passes mail2news gateways, and/or is
>> used in an Archived-At URL.
>
> I admit that I only spent a little while examining this, so
> perhaps Eric Burger can give a more definitive answer. However,
> looking at the examples in -07, it sure looks to me like
> message ids are not intended to be globally unique forever,
> since, since they're way too short.
>
>
>> | The Message-ID header field contains a unique message identifier.
>> | Netnews is more dependent on message identifier uniqueness and fast
>> | comparison than Email is
>> [...]
>> | The global uniqueness requirement for in [RFC2822]
>> | is to be understood as applying across all protocols using
>> | such message identifiers, and across both Email and Netnews
>> | in particular.
>>
>>> (2) It is prohibitive for an attacker who has seen one or more
>>> valid Message-IDs to generate additional valid Message-IDs.
>>
>> That would match pseudo-random number, but a "worldwide unique
>> forever" Message-ID can boil down to timestamp @ domain (plus
>> magic to avoid collisions for various Message-ID generators
>> for a given domain or subdomain).
>
> I'm not sure I get the point you're trying to make here. Yes,
> if you want to have unforgeability this is a stronger requirement
> than worldwide uniquness.
>
> -Ekr
>
>
>
>
> _______________________________________________
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
From simplbps@mail.tld.net Sat May 17 13:28:35 2008
Return-Path:
X-Original-To: ietfarch-simple-archive@core3.amsl.com
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0F81C28C456
for ; Sat, 17 May 2008 13:28:35 -0700 (PDT)
X-Quarantine-ID: <3tGXodhOVTin>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA
\256 Official Site [...]
X-Spam-Flag: NO
X-Spam-Score: -37.057
X-Spam-Level:
X-Spam-Status: No, score=-37.057 tagged_above=-999 required=5
tests=[FH_RELAY_NODNS=1.451, GB_I_LETTER=-2,
HELO_DYNAMIC_IPADDR=2.935, HTML_IMAGE_ONLY_20=1.808,
HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.556, MANGLED_OFF=2.3,
MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.672,
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.509,
RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_NONE=0.1,
SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_BLACK=20,
URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URI_NOVOWEL=2.543,
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 3tGXodhOVTin
for ;
Sat, 17 May 2008 13:28:34 -0700 (PDT)
Received: from ip224-124-173-82.adsl2.versatel.nl (ip224-124-173-82.adsl2.versatel.nl [82.173.124.224])
by core3.amsl.com (Postfix) with SMTP id 5FD5828C40B
for ; Sat, 17 May 2008 13:28:33 -0700 (PDT)
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Message-Id: <20080517-72835.9488.qmail@ip224-124-173-82.adsl2.versatel.nl>
To:
Subject: Dear simple-archive@ietf.org May 89% 0FF
From: VIAGRA ® Official Site
MIME-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Date: Sat, 17 May 2008 13:28:33 -0700 (PDT)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service
advertised. Prices and item availability subject to change without notice.
Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From c.iacometti@soveraedizioni.com Sun May 18 11:15:42 2008
Return-Path:
X-Original-To: ietfarch-simple-archive@core3.amsl.com
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D1A803A6DB4;
Sun, 18 May 2008 11:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -88.325
X-Spam-Level:
X-Spam-Status: No, score=-88.325 tagged_above=-999 required=5
tests=[FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.935,
RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5,
RAZOR2_CHECK=0.5, RCVD_IN_DSBL=0.753, RCVD_IN_PBL=0.509,
RCVD_IN_SORBS_DUL=1.615, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812,
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 7twfaWd1lvUw; Sun, 18 May 2008 11:15:42 -0700 (PDT)
Received: from client-200.106.103.16.speedy.net.pe (unknown [200.106.103.16])
by core3.amsl.com (Postfix) with SMTP id A6C713A67E2;
Sun, 18 May 2008 11:15:34 -0700 (PDT)
X-Originating-IP: 188.203.255.228 by smtp.200.106.103.16; Sun, 18 May 2008 14:15:33 -0500
Message-ID:
From: "Burton Briggs"
Reply-To: "Burton Briggs"
To: saad@ietf.org
Subject: Trim line or sport watch? You choose
Date: Sun, 18 May 2008 14:15:33 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit
Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive.
http://tynehiga08215.blogspot.com/
From c.pouw@topselectgroep.nl Sun May 18 13:02:48 2008
Return-Path:
X-Original-To: ietfarch-simple-archive@core3.amsl.com
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1853D3A6DD6;
Sun, 18 May 2008 13:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -72.808
X-Spam-Level:
X-Spam-Status: No, score=-72.808 tagged_above=-999 required=5
tests=[FB_REPLICA_ROLEX=3.157, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994,
GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.52, HELO_EQ_DSL=1.129,
RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5,
RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.509, RCVD_IN_XBL=2.896, RDNS_NONE=0.1,
REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812,
SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666,
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 gCKMkJ3dXyNH; Sun, 18 May 2008 13:02:40 -0700 (PDT)
Received: from adsl190-26129088.dyn.etb.net.co (unknown [190.26.129.88])
by core3.amsl.com (Postfix) with SMTP id 74CD93A6DCE;
Sun, 18 May 2008 13:02:29 -0700 (PDT)
X-Originating-IP: 61.20.254.148 by smtp.190.26.129.88; Sun, 18 May 2008 16:02:30 -0500
Message-ID:
From: "Leola Conner"
Reply-To: "Leola Conner"
To: sherri.hilton@ietf.org
Subject: The discreet replica store
Date: Sun, 18 May 2008 16:02:30 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit
When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices!
http://duxuvupu46741.blogspot.com/
From cablevision@cablevisionsa.com Mon May 19 16:35:59 2008
Return-Path:
X-Original-To: ietfarch-simple-archive@core3.amsl.com
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 039583A6908;
Mon, 19 May 2008 16:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -65.701
X-Spam-Level:
X-Spam-Status: No, score=-65.701 tagged_above=-999 required=5
tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451,
FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395,
RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961,
RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877,
RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808,
SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666,
SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 u4e8G6rKHk6B; Mon, 19 May 2008 16:35:58 -0700 (PDT)
Received: from 168-226-12-64.speedy.com.ar (unknown [168.226.12.64])
by core3.amsl.com (Postfix) with SMTP id EA3413A6A62;
Mon, 19 May 2008 16:35:04 -0700 (PDT)
X-Originating-IP: 236.222.226.32 by smtp.168.226.12.64; Mon, 19 May 2008 19:35:01 -0500
Message-ID:
From: "Rosanne Hooker"
Reply-To: "Rosanne Hooker"
To: saad@ietf.org
Subject: Rolex replica is a ultimate gift
Date: Mon, 19 May 2008 19:35:01 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit
What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted.
http://zukezusetum25.blogspot.com/
Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy!
http://zukezusetum25.blogspot.com/
From simple-bounces@ietf.org Tue May 20 03:04:07 2008
Return-Path:
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 899CC28C169;
Tue, 20 May 2008 03:04:05 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8D84A28C0F7
for ; Tue, 20 May 2008 03:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5yIolomh6eot for ;
Tue, 20 May 2008 03:03:50 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])
by core3.amsl.com (Postfix) with ESMTP id 036D73A6846
for ; Tue, 20 May 2008 03:03:50 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
0552C213A8; Tue, 20 May 2008 12:03:50 +0200 (CEST)
X-AuditID: c1b4fb3e-ad997bb000004ec0-e4-4832a205b389
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
D2555216AA; Tue, 20 May 2008 12:03:49 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 20 May 2008 12:03:08 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 20 May 2008 12:03:08 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se
[131.160.33.3])
by mail.lmf.ericsson.se (Postfix) with ESMTP id 084C52441;
Tue, 20 May 2008 13:03:08 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])
by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C190E4DBA1;
Tue, 20 May 2008 13:03:07 +0300 (EEST)
Received: from n68.nomadiclab.com (localhost [IPv6:::1])
by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 78E8C4DB83;
Tue, 20 May 2008 13:03:07 +0300 (EEST)
Message-ID: <4832A1DB.7090000@ericsson.com>
Date: Tue, 20 May 2008 13:03:07 +0300
From: Salvatore Loreto
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: jdrosen@cisco.com
References: <822C0A32-4BA8-422B-8FE0-5C3F5D6F739B@estacado.net>
In-Reply-To: <822C0A32-4BA8-422B-8FE0-5C3F5D6F739B@estacado.net>
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 20 May 2008 10:03:08.0241 (UTC)
FILETIME=[B42B1C10:01C8BA60]
X-Brightmail-Tracker: AAAAAA==
Cc: simple@ietf.org
Subject: Re: [Simple] comments on draft-ietf-simple-view-sharing-00
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
List-Unsubscribe: ,
List-Archive: