http://blog.gmane.org/gmane.ietf.apps-discuss hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.apps-discuss/7098 <pre>I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Grüße, Carsten --------------------------------- Document: draft-ietf-dccp-udpencap-10 Title: Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) Reviewer: Carsten Bormann Review Date: 2012-05-26 IETF Last Call Date: 2012-05-12, for 2012-05-25 ** Summary: This draft is ready for publication as a Proposed Standard after minor revisions. ** Major Issues: This document does not have any blocking issues. One observation is that there was no attempt to exploit any economies in header sizes that might be available for this encapsulation. E.g., the DCCP c</pre> Carsten Bormann 2012-05-26T21:00:29 http://comments.gmane.org/gmane.ietf.apps-discuss/7058 <pre>I apologise if this has already been discussed, but this list has become nearly unreadable recently. &lt;http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-01.txt&gt; motivates SSS with: """ 2. When to Use these Structured Syntax Suffixes Each of the Structured Syntax Suffixes defined in this document is appropriate for use when the media type identifies the semantics of the protocol payload. That is, knowing the semantics of the specific media type provides for more specific processing of the content than that afforded by generic processing of the underlying representation. At the same time, using the suffix allows receivers of the media types to do generic processing of the underlying representation in cases where * they do not need to perform special handling of the particular semantics of the exact media type, and, * there is no special knowledge needed by such a generic processor in order to parse that underlying representation other than w</pre> Mark Nottingham 2012-05-24T01:35:37 http://comments.gmane.org/gmane.ietf.apps-discuss/7054 <pre>This draft has completed an IETF Last Call, with some comments received for consideration and integration into the document. Unfortunately, the authors have advised me that they will not have time in the next couple of months (at least) to complete the edits so that it can go to the IESG. I have (gratefully!) appointed SM as the new document editor. He has agreed to fold in the Last Call comments so that we can progress the document to publication. I expect we should see a review of the LC comments from him and a new version shortly. Thanks, SM! -MSK, APPSAWG co-chair _______________________________________________ apps-discuss mailing list apps-discuss&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss </pre> Murray S. Kucherawy 2012-05-23T17:26:09 http://comments.gmane.org/gmane.ietf.apps-discuss/7044 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Filename : draft-ietf-appsawg-media-type-suffix-regs-01.txt Pages : 9 Date : 2012-05-22 A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-suffix-regs-01.txt </pre> internet-drafts< at >ietf.org 2012-05-23T02:13:03 http://comments.gmane.org/gmane.ietf.apps-discuss/7040 <pre> Major: Section 5.8: still lists "Open issue: handling of lifetime parameters." Minor: Section 3.4: "RFC editor, remove the remainder of this subjection prior to publication.", do you mean "subsection" here? Section 5:  The format of "length" should be more clearly defined her.  A more detailed definition appears to live as the last three sentences in 5.6.3, which seems odd. Nits: Section 5.5.1 &amp; 5.5.2: Is the phrase "It is always critical." something with specific meaning?  Otherwise simply stating that these tokens are REQUIRED, is probably sufficient. Section 6: 3rd paragraph, "procedur" needs an "e" on the end. Section 7.1:  "[this spec" wants a closing square bracket. Section 7.3:  The choice of registered values seems odd;  non-sequential, and slightly inconsistent (request vs. response not in consistent numerical order).  Doesn't matter since it's constants._______________________________________________ apps-discuss mailing list apps-discuss&lt; at &gt;ietf.org https://www.ietf.org/mailman</pre> William Mills 2012-05-22T23:31:08 http://comments.gmane.org/gmane.ietf.apps-discuss/7032 <pre>I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ledbat-congestion-09 Title: Low Extra Delay Background Transport (LEDBAT) Reviewer: Vijay K. Gurbani Review Date: May-22-2012 IETF Last Call Date: Unknown IESG Telechat Date: May-24-2012 Summary: This draft is ready for publication as an Experimental Standard but it has some minor issues (detailed below) that should be addressed. Major issues: 0 Minor issues: 3 Major issues: 2 Minor: - S3.3: You probably need an accessor to get the timestamp; i.e.: OLD: remote_timestamp = data_packet.timestamp NEW: remote_timestamp = data_packet.timestamp() - S3.3: The text says that the receiver ".</pre> Vijay K. Gurbani 2012-05-22T20:24:57 http://comments.gmane.org/gmane.ietf.apps-discuss/7029 <pre>I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate&lt;http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate&gt;). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-farresnickel-ipr-sanctions Title: Sanctions Available for Application to Violators of IETF IPR Policy Reviewer: Murray S. Kucherawy Review Date: May 22, 2012 IETF Last Call Date: ends June 4, 2012 IESG Telechat Date: not scheduled Summary: This document is ready for publication as an Informational document, modulo my two issues for discussion below. Major Issues: 1. Should this not be a BCP? The polk draft describes ways to encourage compliance, while this one talks about penalties for non-compliance. That seems too severe for Info</pre> Murray S. Kucherawy 2012-05-22T19:29:07 http://comments.gmane.org/gmane.ietf.apps-discuss/7024 <pre>Hello, I am forwarding this review to have a reference for the tracker. I have been selected as the Applications Area Directorate reviewer for this draft. (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-polk-ipr-disclosure-03 Title: Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules Reviewer: Murray S. Kucherawy Review Date: May 22, 2012 IETF Last Call Date: ends May 28, 2012 IESG Telechat Date: not scheduled Summary: This draft is ready for publication as an Informational RFC, though I have a question about that proposed status. Major Issues: 1. Should this not be a BCP? Minor Issues: (none) Nits: 1. Section 1.1: s/section/Section/ Appendix A, several locations: a "&amp;t;" entity should probably </pre> Murray S. Kucherawy 2012-05-22T19:06:43 http://comments.gmane.org/gmane.ietf.apps-discuss/7020 <pre>I have been selected as the Applications Area Directorate reviewer for this draft. (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-polk-ipr-disclosure-03 Title: Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules Reviewer: Murray S. Kucherawy Review Date: May 22, 2012 IETF Last Call Date: ends May 28, 2012 IESG Telechat Date: not scheduled Summary: This draft is ready for publication as an Informational RFC, though I have a question about that proposed status. Major Issues: 1. Should this not be a BCP? Minor Issues: (none) Nits: 1. Section 1.1: s/section/Section/ Appendix A, several locations: a "&amp;t;" entity should probably be "&amp;lt;". -MSK _______________________________________________ apps-discuss ma</pre> Murray S. Kucherawy 2012-05-22T18:51:41 http://comments.gmane.org/gmane.ietf.apps-discuss/7018 <pre>Hi appsawg folks, The above two drafts haven't received much attention lately. In March and April they each had some independent threads of discussion but they weren't resolved, and no new version or specific proposed changes with consensus have appeared. In particular, there is no apparent consensus to progress them as-is nor is there consensus that the issues raised are off in the weeds. So we're stuck. It might be helpful to the author to have a few more reviewers. They are both short documents. Please take a moment to review them, perhaps in the context of the previous threads, and provide some commentary. Those of you that have commented before, perhaps you could summarize your concerns (or simply reference them) to help the author collate and apply feedback. As has been pointed out, we have several documents in progress here and a couple in Call For Adoption that we are now holding until some of the current docket clears. Having two that are fully idle is, thus, a concern. If they continue t</pre> Murray S. Kucherawy 2012-05-22T18:42:08 http://comments.gmane.org/gmane.ietf.apps-discuss/7014 <pre>I have been selected as the Applications Area Directorate reviewer for this draft (for background on AppsDir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). The comments in this review do not bear more weight than comments submitted by an individual during a Last Call. It is suggested that the author asks the document shepherd for guidance about any changes suggested in a review. Document: draft-ietf-dnsext-dnssec-bis-updates-18 Title: Clarifications and Implementation Notes for DNSSECbis Reviewer: S. Moonesamy Review Date: May 22, 2012 IETF Last Call Date: May 17, 2012 Summary: This document is not ready for publication as a Proposed Standard. The proposal is a collection of technical clarifications to the DNSSECbis document set. DNSSEC is useful for application-related specifications which perform service location. The proposal does not directly affect any application-related specification. The proposal seems targeted at implementers who are fully con</pre> S Moonesamy 2012-05-22T17:12:27 http://comments.gmane.org/gmane.ietf.apps-discuss/7011 <pre>Hi folks, Today many protocols define their own "service discovery" protocols (e.g., &lt;http://tools.ietf.org/html/rfc6186&gt;, &lt;https://datatracker.ietf.org/doc/draft-daboo-srv-caldav/&gt;, &lt;http://tools.ietf.org/html/rfc6125&gt;). often than not, a client device actually wants to be able to discover all services a "service provider" has available or provisioned for the user. i.e., a user expects email, calendar, contacts, IM, directory etc to be setup in one step by the client, rather than having to go and setup each service separately. Whilst a client can present a single UI for such an "aggregated service discovery" it still has to go use separate discovery protocols for each service. This is expensive - lots of separate DNS lookups, etc. Several proprietary systems offer and "aggregated service discovery" protocol - in its simplest form a GET on a well known URI that returns an XML document listing available services and other useful configuration information. It is time we had such a protocol for </pre> Cyrus Daboo 2012-05-22T15:00:22 http://comments.gmane.org/gmane.ietf.apps-discuss/7007 <pre>As we prepare to bring webfinger into appsawg, it looks a lot like there's substantial discussion just on the point of the proposed "acct:" scheme. So, a question for those tracking the discussion: Is this a big enough topic that it should be split into its own document? This would be a useful thing to decide as we figure out how to handle the work once it enters working group mode. (This by itself has me wondering if we should revisit the conversation about whether webfinger needs its own working group, but I'll leave it to Barry and Pete to make that call.) -MSK _______________________________________________ apps-discuss mailing list apps-discuss&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss </pre> Murray S. Kucherawy 2012-05-22T07:22:53 http://comments.gmane.org/gmane.ietf.apps-discuss/7003 <pre>I have been selected as the Applications Area Directorate reviewer for this draft (for background on AppsDir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). The comments in this review do not bear more weight than comments submitted by an individual during a Last Call. It is suggested that the author ask the document shepherd for guidance about any changes suggested in a review. Please note that this is a follow-up to a previous review. Document: draft-melnikov-smtp-priority-13 Title: Simple Mail Transfer Protocol extension for Message Transfer Priorities Reviewer: S. Moonesamy Review Date: May 21, 2012 IETF Last Call Date: May 28, 2012 Summary: This draft is ready for publication as a Proposed Standard. This memo defines an extension to the SMTP service whereby messages are sent with a priority to enable receivers to take this into account. The draft is well-written. Major issues: None Minor issues: In Section 10: I could have classified this under</pre> S Moonesamy 2012-05-21T22:05:25 http://comments.gmane.org/gmane.ietf.apps-discuss/7002 <pre>Hi Murray, I have a few comments on draft-ietf-appsawg-received-state-01. It's ready to ship. Issues: In Section 3: 'This memo creates a new trace field clause, called "state", which can be used to indicate the nature of a delay imposed on relaying of a message toward its recipient(s).' Does this apply to all trace fields (see draft-levine-trace-header-registry-01 for some of those header fields)? Nits: In Section 5: "that the Received fields present on a message could be counted by" I suggest using "header fields". The IANA reference can be informative. Regards, -sm </pre> SM 2012-05-21T19:56:13 http://comments.gmane.org/gmane.ietf.apps-discuss/6999 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-jones-appsawg-webfinger-05.txt Pages : 22 Date : 2012-05-21 This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/inte</pre> internet-drafts< at >ietf.org 2012-05-21T14:35:32 http://comments.gmane.org/gmane.ietf.apps-discuss/6988 <pre>Hi all, I'm writing in support of publication ofhttps://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state. From 2009-2012 I was responsible for all inbound email delivery and anti-abuse functions at Hotmail, and on numerous occasions was called on by internal product and legal folks, external law enforcement, other mailbox providers and countless other senders and receivers to figure out why an email didn't immediately transit from sender to recipient. Received headers were a good debugging tool but didn't provide much satisfaction in terms of "why", just "where". Adding a state field would seem to help that problem if sufficient folks adopted it, so I'd like to see a standardized guideline published in support of that. Regards, Paul _______________________________________________ apps-discuss mailing list apps-discuss&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss </pre> Paul Midgen 2012-05-19T07:05:56 http://comments.gmane.org/gmane.ietf.apps-discuss/6986 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Indicating Email Handling States in Trace Fields Author(s) : D. Crocker Murray S. Kucherawy Filename : draft-ietf-appsawg-received-state-01.txt Pages : 11 Date : 2012-05-18 This memo registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-received-state-01.txt Internet-Drafts are also available by anonymous FTP at: f</pre> internet-drafts< at >ietf.org 2012-05-19T06:49:27 http://comments.gmane.org/gmane.ietf.apps-discuss/6981 <pre>Dear colleagues, I just read draft-ietf-appsawg-media-type-suffix-regs-00. By and large, I think this document is fine. As far as I can tell, its registrations are all appropriate, though I confess I have not chased all the references to make sure everything is right. They look right to me, so I wasn't inspired to check them all. I have a couple picky points, but they're mostly editorial. First, all of the registrations could be laid out differently. The template has been filled in so that the name of the template item is right up against the text of each item, and it's hard to read. Second, the antecedent of "this" in, 'This document further defines the "application/vnd.wap.wbxml" media type,' is not clear. I think this is probably ready for LC. Best, A </pre> Andrew Sullivan 2012-05-18T21:14:05 http://comments.gmane.org/gmane.ietf.apps-discuss/6961 <pre>Hello, [Bcc to apps-discuss. Please follow up on appsdir&lt; at &gt;] The Applications Area Review Team has been posting reviews to apps-discuss&lt; at &gt; since October 2009. The Applications Area Directorate continued the practice as the objective is to allow open discussion of the reviews. As a reminder, the comments in the reviews do not bear more weight than comments submitted by an individual during a Last Call. The directorate also perform early reviews, i.e. reviews before a last Call is issued, so that there is more time to address the issues. Apps-discuss&lt; at &gt; is also used by APPSAWG. The work in that working group generates a significant amount of mail traffic. When combined with the APPSDIR-related traffic, it turns in a somewhat high volume of mail and it may hamper the work of APPSAWG. It was suggested to me that APPSDIR reviews should be discussed on a different mailing list. In my opinion, it is important that APPSDIR continues the practice of encouraging open discussion of the reviews. I woul</pre> S Moonesamy 2012-05-17T18:58:07 http://comments.gmane.org/gmane.ietf.apps-discuss/6946 <pre>G'day. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-appsawg-media-type-suffix-regs-00 Title: Additional Media Type Structured Syntax Suffixes Reviewer: D. Crocker &lt;dcrocker&lt; at &gt;bbiw.net&gt; Review Date: 17 May 2012 Summary: Content media type names often contain an informal meta-syntax for distinguishing encoding conventions for the media type. The current document formalizes the convention and registered some existing specific uses. The document is straightforward in organization and writing. It is workable in its current form. The Detailed Comments, below suggest some improvements, but none is essential for pub</pre> Dave Crocker 2012-05-17T15:49:34 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.apps-discuss