From discuss-bounces@apps.ietf.org Mon May 15 21:04:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffnxx-0003zF-Vc; Mon, 15 May 2006 21:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfnnD-0000rO-29 for discuss@apps.ietf.org; Mon, 15 May 2006 20:52:07 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffnn9-0006KE-Mc for discuss@apps.ietf.org; Mon, 15 May 2006 20:52:07 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D6BF414228B; Mon, 15 May 2006 17:51:58 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20361-04; Mon, 15 May 2006 17:51:57 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 23993142272; Mon, 15 May 2006 17:51:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v746.2) To: atom-protocol@imc.org, discuss@apps.ietf.org, xml-dir@ietf.org Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-26--217698109 References: From: Lisa Dusseault Subject: Fwd: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) Date: Mon, 15 May 2006 17:51:49 -0700 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-Mailman-Approved-At: Mon, 15 May 2006 21:03:13 -0400 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-26--217698109 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI -- this is an individual submission yet intended for Proposed Standard, so input is most welcome. Lisa Begin forwarded message: > From: The IESG > Date: May 15, 2006 3:02:13 PM PDT > To: IETF-Announce > Subject: Last Call: 'Atom Threading Extensions' to Proposed > Standard (draft-snell-atompub-feed-thread) > Reply-To: iesg@ietf.org > > The IESG has received a request from an individual submitter to > consider the > following document: > > - 'Atom Threading Extensions ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-12. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed- > thread-10.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-26--217698109 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI -- this is an individual = submission yet intended for Proposed Standard, so input is most = welcome.

Lisa

Begin = forwarded message:

From: = The IESG <iesg-secretary@ietf.org>
Date: May 15, 2006 3:02:13 PM = PDT
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Last Call: 'Atom Threading = Extensions' to Proposed Standard=A0 = (draft-snell-atompub-feed-thread)=A0
Reply-To: = iesg@ietf.org

The = IESG has received a request from an individual submitter to consider = the=A0
following document:

- 'Atom = Threading Extensions '
=A0=A0 = <draft-snell-atompub-feed-thread-10.txt> as a Proposed = Standard

The IESG plans to make a decision in the next few = weeks, and solicits
final comments on this = action.=A0 Please send any = comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by = 2006-06-12.

The file can be obtained via


IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

= --Apple-Mail-26--217698109-- From discuss-bounces@apps.ietf.org Wed May 17 20:47:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWeb-0002ei-2p; Wed, 17 May 2006 20:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWea-0002eZ-57 for discuss@apps.ietf.org; Wed, 17 May 2006 20:46:12 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWeY-00068b-NT for discuss@apps.ietf.org; Wed, 17 May 2006 20:46:12 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M2JCJW2Y34002ROL@mauve.mrochek.com> for discuss@apps.ietf.org; Wed, 17 May 2006 17:46:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1147913019; h=Date: From:Subject:MIME-version; b=uEYQuKXo2BP8VKw+77FVsptkOFZDRRPH3pPxSV Xpxnry0/UuyMB9Y+qQ04tCydIemQm4KdVFnIXGviKXyjdaXA== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M2HB0JPEPC0008CX@mauve.mrochek.com>; Wed, 17 May 2006 17:46:06 -0700 (PDT) To: Lisa Dusseault Message-id: <01M2JCJVC2TG0008CX@mauve.mrochek.com> Date: Wed, 17 May 2006 17:45:42 -0700 (PDT) From: Ned Freed Subject: Re: Fwd: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) In-reply-to: "Your message dated Mon, 15 May 2006 17:51:49 -0700" MIME-version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: discuss@apps.ietf.org, atom-protocol@imc.org, xml-dir@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > FYI -- this is an individual submission yet intended for Proposed > Standard, so input is most welcome. I have a couple of comments, all minor. The sentence at the beginning of section 3 is confusing (to me at least). it says: The "in-reply-to" element is used to indicate that an entry is a response to another resource and MUST contain either or both the "ref" and "href" attributes. Unless you read it carefully it sounds like the MUST requirement applies to the referenced entry, not the in-reply-to element itself. How about changing it to something like: The "in-reply-to" element is used to indicate that an entry is a response to another resource. The element MUST contain either or both the "ref" and "href" attributes. Now, I have a lot more experience with XML Schema than with Relax NG so maybe I'm reading this wrong, but the Relax NG definition seems to say that the source attribute can only appear when the ref attribute is present and the type attribute can only appear when the href attribute is present. But this isn't spelled out in the (normative) text. How about adding "When the ref attribute is present" before "The 'source' attribute ..." and "When the href attribute is present" before "The 'type' attribute ..."? Finally, the document seems a bit short on specifics of how the in-reply-to element is actually used. Although the underlying semantic model here seems to be simpler than email's in-reply-to/references scheme (a good thing IMO), perhaps some words about whether you need to list just the parent(s) and not the grandparent(s) would be in order. There were certainly differences of opinion about this in the days of RFC 822 which RFC 2822 section 3.6.4 cleared up. That's it! Ned From discuss-bounces@apps.ietf.org Thu May 18 13:47:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmaZ-0001Cq-6T; Thu, 18 May 2006 13:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWrV-00087e-Iu for discuss@apps.ietf.org; Wed, 17 May 2006 20:59:33 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWrT-0006Su-B8 for discuss@apps.ietf.org; Wed, 17 May 2006 20:59:33 -0400 Received: by wr-out-0506.google.com with SMTP id i12so326497wra for ; Wed, 17 May 2006 17:59:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=E2//mkDySf1RQDUIbKb2K7Cn27QmAKQi6WnikGUls6DFOmaLD70fjn01CTeQsHymDnv9d9CIQ6e6GZJe/TUJKCTHh0Lmhio9mZX2+ZAvLTjTLaxl9BaVCDRpF83OoSDyaHeWx6scI8EtXaK85hUuNfbPunmyOS25K2G0s4/ehDo= Received: by 10.54.134.15 with SMTP id h15mr3150049wrd; Wed, 17 May 2006 17:59:30 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g3sm216201wra.2006.05.17.17.59.29; Wed, 17 May 2006 17:59:30 -0700 (PDT) Message-ID: <446BC6EE.9000902@gmail.com> Date: Wed, 17 May 2006 17:59:26 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Ned Freed Subject: Re: Fwd: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) References: <01M2JCJVC2TG0008CX@mauve.mrochek.com> In-Reply-To: <01M2JCJVC2TG0008CX@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Thu, 18 May 2006 13:47:05 -0400 Cc: discuss@apps.ietf.org, atom-protocol@imc.org, xml-dir@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned Freed wrote: >> FYI -- this is an individual submission yet intended for Proposed >> Standard, so input is most welcome. > > I have a couple of comments, all minor. > Thank you for taking the time. >[snip] > The "in-reply-to" element is used to indicate that an entry is a > response to another resource. The element MUST contain either or both the > "ref" and "href" attributes. > Yes, this makes sense. Also, I am changing this definition making ref required in all cases. > Now, I have a lot more experience with XML Schema than with Relax NG so > maybe I'm reading this wrong, but the Relax NG definition seems to say > that the source attribute can only appear when the ref attribute is present > and the type attribute can only appear when the href attribute is present. > But this isn't spelled out in the (normative) text. How about adding > "When the ref attribute is present" before "The 'source' attribute ..." and > "When the href attribute is present" before "The 'type' attribute ..."? > Yes. I'll make the change. > Finally, the document seems a bit short on specifics of how the > in-reply-to element is actually used. Although the underlying semantic > model here seems to be simpler than email's in-reply-to/references scheme > (a good thing IMO), perhaps some words about whether you need to list just > the parent(s) and not the grandparent(s) would be in order. There > were certainly differences of opinion about this in the days of RFC 822 > which RFC 2822 section 3.6.4 cleared up. > I will take another look at 2822 and see if I can strike the right balance. > That's it! > Thanks again. > Ned > > From discuss-bounces@apps.ietf.org Thu May 18 20:15:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgsd5-0002yT-AB; Thu, 18 May 2006 20:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgriE-0002pX-Rq for discuss@apps.ietf.org; Thu, 18 May 2006 19:15:22 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgriE-0005bz-4p for discuss@apps.ietf.org; Thu, 18 May 2006 19:15:22 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BDE20142297; Thu, 18 May 2006 16:15:16 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11601-05; Thu, 18 May 2006 16:15:14 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 98F0214228A; Thu, 18 May 2006 16:15:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) References: Content-Type: multipart/alternative; boundary=Apple-Mail-20-35697861 Message-Id: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> From: Lisa Dusseault Subject: Fwd: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard Date: Thu, 18 May 2006 16:15:05 -0700 To: discuss@apps.ietf.org, XMPP WG List , Atom , ietf-nntp@lists.eyrie.org X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 X-Mailman-Approved-At: Thu, 18 May 2006 20:14:05 -0400 Cc: simon@josefsson.org, James M Snell , clive@demon.net, doug_otis@trendmicro.com X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-20-35697861 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This announcement is for a document that will obsolete RFC3548, which is referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax (RFC4287). There are also a few drafts that reference RFC3548 that caught my eye: - draft-ietf-nntpext-base, which is in RFC ED queue - draft-josefsson-sasl-gs2-00 - draft-otis-dkim-options-00 - draft-snell-atompub-author-extensions-00 thanks, Lisa Begin forwarded message: > From: The IESG > Date: May 18, 2006 7:51:48 AM PDT > To: IETF-Announce > Cc: Internet Architecture Board , RFC Editor editor@rfc-editor.org> > Subject: Protocol Action: 'The Base16, Base32, and Base64 Data > Encodings' to Proposed Standard > > The IESG has approved the following document: > > - 'The Base16, Base32, and Base64 Data Encodings ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product > of an > IETF Working Group. > > The IESG contact person is Ted Hardie. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-04.txt > > Technical Summary > > This document describes the commonly used base 64, base 32, and base > 16 encoding schemes. It also discusses the use of line-feeds in > encoded data, use of padding in encoded data, use of non-alphabet > characters in encoded data, and use of different encoding > alphabets. > It obsoletes the descriptions in RFC 3548. > > Working Group Summary > > This work is the product of an individual submitter. There were > significant > IETF Last Call comments, and the draft was updated to respond to > them. > > Protocol Quality > > This document was reviewed for the IESG by Ted Hardie. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-20-35697861 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 This announcement is for a = document that will obsolete RFC3548, which is referenced by a couple = APPS area RFCs:=A0 XMPP (RFC3920) and Atom Syntax (RFC4287).

There are also a few drafts = that reference RFC3548 that caught my eye:

=A0- draft-ietf-nntpext-base, which is in RFC ED = queue
=A0- = =A0draft-josefsson-sasl-gs2-00
=A0- = draft-otis-dkim-options-00

thanks,
From: = The IESG <iesg-secretary@ietf.org>
Date: May 18, 2006 7:51:48 AM = PDT
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>= ;
Subject: Protocol Action: 'The Base16, = Base32, and Base64 Data=A0 = Encodings' to Proposed Standard=A0

The = IESG has approved the following document:

- 'The = Base16, Base32, and Base64 Data Encodings '
=A0=A0 = <draft-josefsson-rfc3548bis-04.txt> as a Proposed = Standard

This document has been reviewed in the IETF but is = not the product of an
IETF Working Group.=A0

The IESG = contact person is Ted Hardie.

A URL of this Internet-Draft = is:

Technical Summary

=A0 This document describes the = commonly used base 64, base 32, and base
=A0=A0 16 encoding schemes.=A0 It also discusses the use of = line-feeds in
=A0=A0 encoded data, use of = padding in encoded data, use of non-alphabet
=A0=A0 = characters in encoded data, and use of different encoding = alphabets.
=A0=A0 It obsoletes the = descriptions in RFC 3548.

Working Group Summary

=A0This work is the product of an = individual submitter.=A0 = There were significant
=A0IETF Last Call comments, and = the draft was updated to respond to them.

Protocol = Quality

=A0This = document was reviewed for the IESG by Ted Hardie.


IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

= --Apple-Mail-20-35697861-- From discuss-bounces@apps.ietf.org Sat May 20 22:16:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhdSj-0002YQ-VF; Sat, 20 May 2006 22:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhdSi-0002YF-3o for discuss@apps.ietf.org; Sat, 20 May 2006 22:14:32 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhdSg-0007xo-Me for discuss@apps.ietf.org; Sat, 20 May 2006 22:14:32 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M2NMIB3CUO00967V@mauve.mrochek.com> for discuss@apps.ietf.org; Sat, 20 May 2006 19:14:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1148177662; h=Date: From:Subject:MIME-version:Content-type; b=pGz0mgmwJCOTYBrLf9HJBxezP l+pzUD7R5/DSgpZ0nlaCIkm1LQcggdeFOD05+OeUl1ZCke+eF8sdKbSgfNEHg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M2N1EPP25C0008CX@mauve.mrochek.com>; Sat, 20 May 2006 19:14:18 -0700 (PDT) To: James M Snell Message-id: <01M2NMI8J3NS0008CX@mauve.mrochek.com> Date: Sat, 20 May 2006 19:13:48 -0700 (PDT) From: Ned Freed Subject: Re: [xml-dir] Re: Fwd: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) In-reply-to: "Your message dated Wed, 17 May 2006 17:59:26 -0700" <446BC6EE.9000902@gmail.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8 References: <01M2JCJVC2TG0008CX@mauve.mrochek.com> <446BC6EE.9000902@gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: discuss@apps.ietf.org, atom-protocol@imc.org, Ned Freed , xml-dir@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Ned Freed wrote: > >> FYI -- this is an individual submission yet intended for Proposed > >> Standard, so input is most welcome. > > > > I have a couple of comments, all minor. > > > Thank you for taking the time. > >[snip] > > The "in-reply-to" element is used to indicate that an entry is a > > response to another resource. The element MUST contain either or both the > > "ref" and "href" attributes. > > > Yes, this makes sense. Also, I am changing this definition making ref > required in all cases. Good - I think that makes even more sense. > > Now, I have a lot more experience with XML Schema than with Relax NG so > > maybe I'm reading this wrong, but the Relax NG definition seems to say > > that the source attribute can only appear when the ref attribute is present > > and the type attribute can only appear when the href attribute is present. > > But this isn't spelled out in the (normative) text. How about adding > > "When the ref attribute is present" before "The 'source' attribute ..." and > > "When the href attribute is present" before "The 'type' attribute ..."? > > > Yes. I'll make the change. > > Finally, the document seems a bit short on specifics of how the > > in-reply-to element is actually used. Although the underlying semantic > > model here seems to be simpler than email's in-reply-to/references scheme > > (a good thing IMO), perhaps some words about whether you need to list just > > the parent(s) and not the grandparent(s) would be in order. There > > were certainly differences of opinion about this in the days of RFC 822 > > which RFC 2822 section 3.6.4 cleared up. > > > I will take another look at 2822 and see if I can strike the right balance. Sounds good. Ned