Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

2012-03-06 Thread Alexey Melnikov
On 05/03/2012 19:40, Barry Leiba wrote: 2. I, too, noticed all the lower-case should and may words. I suggest that the best way to handle this is to make the following change to the RFC 2119 citation text at the beginning of section 2: NEW The key words MUST, MUST NOT, REQUIRED, SHALL,

Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

2012-03-06 Thread Alexey Melnikov
On 05/03/2012 18:00, Murray S. Kucherawy wrote: -Original Message- From: Alexey Melnikov [mailto:alexey.melni...@isode.com] Sent: Monday, March 05, 2012 4:00 AM To: Murray S. Kucherawy Cc:ietf@ietf.org Subject: Re: Last Call:draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer

Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

2012-03-06 Thread Alexey Melnikov
Hi Ned, On 05/03/2012 15:34, Ned Freed wrote: That said, I think an important omission in this document is that it only allows MSA's to change message priorities to conform to site policy. MTAs should also be allowed to do this. Can you elaborate a bit more on possible use cases?

Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

2012-03-06 Thread t.petch
I am finding myself with some unfamiliar bedfellows on this issue, but yes, it should be approved - see inline. Tom Petch - Original Message - From: John C Klensin john-i...@jck.com To: stbry...@cisco.com Cc: ietf@ietf.org Sent: Friday, March 02, 2012 12:04 AM Subject: Re: Last

Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

2012-03-06 Thread Eliot Lear
Hi, I speak now as an individual and in no other capacity with no other hats on. On 3/6/12 11:31 AM, t.petch wrote: I am finding myself with some unfamiliar bedfellows on this issue, but yes, it should be approved - see inline. We claim ownership of the name space on behalf of all parties,

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Tony Finch
Mark Andrews ma...@isc.org wrote: I would say DNS master file representation - DNS wire representation is one of the main issues on the provisioning side. This conversion needs to be done at some point. John's draft addresses that. The other this is verification of the input. What kind of

Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Xavier Marjou
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not believe I'm the only one. Hence, would it be possible to

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Julian Reschke
On 2012-03-06 14:41, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not believe I'm the

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Simon Perreault
On 2012-03-06 08:51, Julian Reschke wrote: On 2012-03-06 14:41, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Yoav Nir
Even better, also add the XML2RFC output if it's available at the same time: http://tools.ietf.org/id/draft-name.html for example, (just picking my own latest draft as an example): http://tools.ietf.org/id/draft-nir-websec-extended-origin-02.html I don't know which drafts get this version

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Riccardo Bernardini
On Tue, Mar 6, 2012 at 2:53 PM, Simon Perreault simon.perrea...@viagenie.ca wrote: On 2012-03-06 08:51, Julian Reschke wrote: On 2012-03-06 14:41, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Julian Reschke
On 2012-03-06 14:56, Yoav Nir wrote: Even better, also add the XML2RFC output if it's available at the same time: http://tools.ietf.org/id/draft-name.html for example, (just picking my own latest draft as an example): http://tools.ietf.org/id/draft-nir-websec-extended-origin-02.html +1 I

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Hector
+1. This will save a few typing and clicks. Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft.

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Russ Housley
I would be much happier with a link to the datatracker HTML version: https://datatracker.ietf.org/doc/draft-name/ Would this meet your needs? Russ On Mar 6, 2012, at 8:41 AM, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Randy Bush
I would be much happier with a link to the datatracker HTML version: https://datatracker.ietf.org/doc/draft-name/ Would this meet your needs? then we can each have our cake and eat it too. but i fear folk may just want the bright shiny. randy ___

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Dave Crocker
On 3/6/2012 6:12 AM, Russ Housley wrote: I would be much happier with a link to the datatracker HTML version: https://datatracker.ietf.org/doc/draft-name/ +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message alpine.lsu.2.00.1203061314260.22...@hermes-2.csi.cam.ac.uk, Tony F inch writes: Mark Andrews ma...@isc.org wrote: I would say DNS master file representation - DNS wire representation is one of the main issues on the provisioning side. This conversion needs to be done at some

Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

2012-03-06 Thread Barry Leiba
Is the following better: tThe Importance xref target=RFC2156/ header field MUST NOT be used for determining      the priority under this Priority Message Handling SMTP extension.      In absence of both the PRIORITY MAIL FROM parameter and the MT-Priority header field,      other message

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Riccardo Bernardini
On Tue, Mar 6, 2012 at 3:24 PM, Randy Bush ra...@psg.com wrote: I would be much happier with a link to the datatracker HTML version: https://datatracker.ietf.org/doc/draft-name/ Would this meet your needs? Yes, it would be fine. From my point of view the two versions are almost equivalent,

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Tony Hansen
It would be acceptable to me, especially since there's a link from there to the tools HTML version. (Look for the html link at the top.) Tony Hansen On 3/6/2012 9:12 AM, Russ Housley wrote: I would be much happier with a link to the datatracker HTML version:

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread John R. Levine
Input -P- DNS server -D- DNS stub -Q- Output P is the provisioning I think you want to break that into the provisioning interface and the data format it produces that the DNS server consumes. (My reason for that is we have a specification for at least such format, with all that implies.) I

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Xavier Marjou
With a link like https://datatracker.ietf.org/doc/draft-name/ (e.g. https://datatracker.ietf.org/doc/draft-nir-websec-extended-origin/ ), I will most often then click again on the html top right link. But I'm fine with it too. On Tue, Mar 6, 2012 at 3:12 PM, Russ Housley hous...@vigilsec.com

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Yoav Nir
The XML2RFC version is not linked from there. If that was added to the Other versions field, that would be great. On Mar 6, 2012, at 5:11 PM, Xavier Marjou wrote: With a link like https://datatracker.ietf.org/doc/draft-name/ (e.g.

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread ned+ietf
Input -P- DNS server -D- DNS stub -Q- Output P is the provisioning I think you want to break that into the provisioning interface and the data format it produces that the DNS server consumes. (My reason for that is we have a specification for at least such format, with all that implies.)

Re: [IETF] Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Warren Kumari
On Mar 6, 2012, at 8:41 AM, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Alessandro Vesely
On 06/Mar/12 04:56, ned+i...@mauve.mrochek.com wrote: On 05/Mar/12 18:09, John Levine wrote: Would you really want to build an SPF or DKIM parser into every DNS server? That's a lot of code that the DNS manager doesn't care about, but the mail manager does. But it would be the same code,

Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

2012-03-06 Thread t.petch
- Original Message - From: Eliot Lear l...@cisco.com To: t.petch daedu...@btconnect.com Cc: John C Klensin john-i...@jck.com; stbry...@cisco.com; ietf@ietf.org Sent: Tuesday, March 06, 2012 12:46 PM Hi, I speak now as an individual and in no other capacity with no other hats on. On

Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

2012-03-06 Thread Rolf E. Sonneveld
On 3/3/12 7:07 PM, ned+i...@mauve.mrochek.com wrote: This draft also defines the MT-Priority header field. �It is quite unusual for a SMTP extension specification to define a mail header field. ... This is my major concern about this protocol as well, as I note in the PROTO writeup (which,

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Tony Finch
John R. Levine jo...@iecc.com wrote: I was also going to mention that. There's a lot of different formats for zone file data, with BIND-ish master files being only one of them. DNS master files are specified in RFC 1035 so it's wrong to imply they are implementation-specific. Tony. --

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread John R. Levine
I was also going to mention that. There's a lot of different formats for zone file data, with BIND-ish master files being only one of them. DNS master files are specified in RFC 1035 so it's wrong to imply they are implementation-specific. They're not implementation specific, but they're

RE: tsv-dir review of draft-garcia-shim6-applicability-03

2012-03-06 Thread Dan Wing
-Original Message- From: Alberto García [mailto:albe...@it.uc3m.es] Sent: Tuesday, March 06, 2012 9:07 AM To: 'Dan Wing'; 'IETF discussion list' Cc: 'Transport Directorate'; tsv-a...@ietf.org; joe.ab...@icann.org; 'marcelo bagnulo braun' Subject: RE: tsv-dir review of

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Alessandro Vesely
On 06/Mar/12 16:00, John R. Levine wrote: We seem to believe that the D part is deployed so that adding new unknown RRTypes is not an issue. I think this is correct, but OTOH someone recently asked about possible issues in this area, and if I remember correctly, received no response.

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Scott Kitterman
On Tuesday, March 06, 2012 06:34:58 PM Alessandro Vesely wrote: On 06/Mar/12 16:00, John R. Levine wrote: We seem to believe that the D part is deployed so that adding new unknown RRTypes is not an issue. I think this is correct, but OTOH someone recently asked about possible issues in

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Barry Leiba
almost equivalent, this latter maybe is more flexible (at the expense of one more click, which is negligible) Re: one more click... https://datatracker.ietf.org/cookies/ Note the third item. Barry ___ Ietf mailing list Ietf@ietf.org

Re: Last Call: draft-snell-atompub-tombstones-15.txt (The Atom deleted-entry Element) to Proposed Standard

2012-03-06 Thread Peter Saint-Andre
Folks, we've issued a second Last Call on this document because based on IESG feedback the intended status has changed from Informational to Proposed Standard. On 3/6/12 10:45 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document:

Re: WG Review: INtermediary-safe SIP session ID (insipid)

2012-03-06 Thread Barry Leiba
A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. ... INtermediary-safe SIP session ID (insipid) I think the working group is a good idea, and I think the charter is fine. Charter away. Just a very, very small point: There's some value in being

RE: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Murray S. Kucherawy
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Xavier Marjou Sent: Tuesday, March 06, 2012 5:42 AM To: IETF Discussion Subject: Add a link to the HTML version in i-d-announce mails ? As a subscriber of the i-d-annou...@ietf.org list, I

RE: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Murray S. Kucherawy
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, March 06, 2012 6:13 AM To: Xavier Marjou Cc: IETF Discussion Subject: Re: Add a link to the HTML version in i-d-announce mails ? I would be much happier with a

RE: tsv-dir review of draft-garcia-shim6-applicability-03

2012-03-06 Thread Alberto García
Hi Dan, Thank you very much for your review | -Mensaje original- | De: Dan Wing [mailto:dw...@cisco.com] | Enviado el: jueves, 01 de marzo de 2012 3:56 | Para: 'IETF discussion list' | CC: 'Transport Directorate'; tsv-a...@ietf.org; joe.ab...@icann.org; | 'marcelo bagnulo braun';

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Julian Reschke
On 2012-03-06 16:26, Yoav Nir wrote: The XML2RFC version is not linked from there. If that was added to the Other versions field, that would be great. ... Indeed. HTMLized plain text is progress over plain text, but properly generated HTML is better. But I fear we're getting close to our

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Yoav Nir
On Mar 6, 2012, at 11:44 PM, Julian Reschke wrote: On 2012-03-06 16:26, Yoav Nir wrote: The XML2RFC version is not linked from there. If that was added to the Other versions field, that would be great. ... Indeed. HTMLized plain text is progress over plain text, but properly generated

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message alpine.bsf.2.00.1203061203020.14...@joyce.lan, John R. Levine wr ites: I was also going to mention that. There's a lot of different formats for zone file data, with BIND-ish master files being only one of them. DNS master files are specified in RFC 1035 so it's wrong to

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Russ Housley
Pictures in RFCs? Come to the RFCFORM BOF to voice opinions on this topic. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread John R. Levine
They're not implementation specific, but they're also not required to interoperate, as the wire format queries and responses are. They are a interchange standard as per RFC 1034. Yes, we all know that. But as I presume you also know, there are plenty of DNS servers that store the zone info

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Peter Saint-Andre
On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message 4f564ac2.1040...@tana.it, Alessandro Vesely writes: On 06/Mar/12 16:00, John R. Levine wrote: We seem to believe that the D part is deployed so that adding new unknown RRTypes is not an issue. I think this is correct, but OTOH someone recently asked about possible issues

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Scott Kitterman
On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote: On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Peter Saint-Andre
On 3/6/12 3:24 PM, Scott Kitterman wrote: On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote: On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Scott Kitterman
On Tuesday, March 06, 2012 03:30:44 PM Peter Saint-Andre wrote: On 3/6/12 3:24 PM, Scott Kitterman wrote: On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote: On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Randall Gellens
At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote: In my working copy I've changed that paragraph to: Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based solely on the names of such parameters (i.e.,

Re: Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Tim Bray
Not that voicing opinions on this topic has ever done any good. -T On Tue, Mar 6, 2012 at 2:15 PM, Russ Housley hous...@vigilsec.com wrote: Pictures in RFCs? Come to the RFCFORM BOF to voice opinions on this topic. Russ ___ Ietf mailing list

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Peter Saint-Andre
On 3/6/12 4:19 PM, Randall Gellens wrote: At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote: In my working copy I've changed that paragraph to: Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based

Re: Last Call: draft-ietf-appsawg-xdash-03.txt

2012-03-06 Thread Peter Saint-Andre
On 3/2/12 5:48 PM, Randall Gellens wrote: Hi all, Hi Randall, thank you for the review and suggested text. Three suggestions for edits: First: I suggest adding a brief note to this text in Appendix B: 2. When parameter names might have significant meaning. However, this case

RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Murray S. Kucherawy
Hey Peter, -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, March 06, 2012 3:32 PM To: Randall Gellens Cc: Mark Nottingham; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Peter Saint-Andre
On 3/6/12 4:46 PM, Murray S. Kucherawy wrote: Hey Peter, Howdy. :) -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, March 06, 2012 3:32 PM To: Randall Gellens Cc: Mark Nottingham; ietf@ietf.org Subject:

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Randall Gellens
At 4:32 PM -0700 3/6/12, Peter Saint-Andre wrote: On 3/6/12 4:19 PM, Randall Gellens wrote: At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote: In my working copy I've changed that paragraph to: Implementations of application protocols MUST NOT programatically discriminate

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread John Levine
Last month I ran into a guy on the dmarc list who complained that his server returns NOTIMP in response to queries for SPF records (because it doesn't implement them) and clients were doing odd things. But it's been a long time since I've run into anyone else like that, so I agree, it's

Re: Last Call: draft-ietf-appsawg-xdash-03.txt

2012-03-06 Thread Randall Gellens
Hi Peter, At 4:42 PM -0700 3/6/12, Peter Saint-Andre wrote: On 3/2/12 5:48 PM, Randall Gellens wrote: Hi all, Hi Randall, thank you for the review and suggested text. Three suggestions for edits: First: I suggest adding a brief note to this text in Appendix B: 2. When

Re: [IETF] Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Barry Leiba
Yup, you are not the only one -- this annoyed me sufficiently that I finally gave in and wrote a Chrome extension to do this for me. Basically it watches the address bard and looks for www.ietf.org/id/foo and, depending on the setting in the options page, will redirect to the Tools or

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Barry Leiba
it would be a very broken implementation, but not something that harmed the Internet or even anyone else whose applications worked properly.  At most it would harm its own user, who I assume would quickly dump it. I don't think harm to the Internet is the bar for MUST. If your implementation

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Randall Gellens
At 7:53 PM -0500 3/6/12, Barry Leiba wrote: it would be a very broken implementation, but not something that harmed the Internet or even anyone else whose applications worked properly. At most it would harm its own user, who I assume would quickly dump it. I don't think harm to the

Re: [IETF] Add a link to the HTML version in i-d-announce mails ?

2012-03-06 Thread Warren Kumari
On Mar 6, 2012, at 7:43 PM, Barry Leiba wrote: Yup, you are not the only one -- this annoyed me sufficiently that I finally gave in and wrote a Chrome extension to do this for me. Basically it watches the address bard and looks for www.ietf.org/id/foo and, depending on the setting in the

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Mark Nottingham
On 07/03/2012, at 10:32 AM, Peter Saint-Andre wrote: On 3/6/12 4:19 PM, Randall Gellens wrote: At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote: In my working copy I've changed that paragraph to: Implementations of application protocols MUST NOT programatically discriminate

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Randall Gellens
At 1:02 PM +1100 3/7/12, Mark Nottingham wrote: On 07/03/2012, at 10:32 AM, Peter Saint-Andre wrote: On 3/6/12 4:19 PM, Randall Gellens wrote: At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote: In my working copy I've changed that paragraph to: Implementations of application

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message alpine.bsf.2.00.1203061711470.25...@joyce.lan, John R. Levine wr ites: They're not implementation specific, but they're also not required to interoperate, as the wire format queries and responses are. They are a interchange standard as per RFC 1034. Yes, we all know that.

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread John R. Levine
However we do have standard presentation/entry formats defined and a good front end will accept those as well. Sigh. Now we're back to people who don't do it my way are wrong, so I guess we're done. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Mark Nottingham
On 07/03/2012, at 1:34 PM, Randall Gellens wrote: At 1:02 PM +1100 3/7/12, Mark Nottingham wrote: On 07/03/2012, at 10:32 AM, Peter Saint-Andre wrote: On 3/6/12 4:19 PM, Randall Gellens wrote: At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote: In my working copy I've changed that

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Randy Bush
To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message 20120307000814.29422.qm...@joyce.lan, John Levine writes: Last month I ran into a guy on the dmarc list who complained that his server returns NOTIMP in response to queries for SPF records (because it doesn't implement them) and clients were doing odd things. But it's been

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread John R. Levine
Last month I ran into a guy on the dmarc list who complained that his server returns NOTIMP in response to queries for SPF records (because it doesn't implement them) and clients were doing odd things. But it's been a long time since I've run into anyone else like that, so I agree, it's not an

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Mark Nottingham
On 07/03/2012, at 1:52 PM, Randy Bush wrote: To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message alpine.bsf.2.00.1203062148410.34...@joyce.lan, John R. Levine wr ites: However we do have standard presentation/entry formats defined and a good front end will accept those as well. Sigh. Now we're back to people who don't do it my way are wrong, so I guess we're done. One

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Randy Bush
One of point of having standard presentation formats is that they facilitate data interchange. bind's zone format is not a standard, and many implementations are not compatible with it. get over it. randy ___ Ietf mailing list Ietf@ietf.org

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message m2obs9f3bj.wl%ra...@psg.com, Randy Bush writes: One of point of having standard presentation formats is that they facilitate data interchange. bind's zone format is not a standard, and many implementations are not compatible with it. get over it. Actually it is STD 13. Get

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Martin Rex
Mark Andrews wrote: John Levine writes: In case it wasn't clear, this is an authoritative server. If this is about permitted RCODEs here http://tools.ietf.org/html/rfc1035#section-4.1.1 then an RCODE of 4 in the response looks like a perfectly valid response for a DNS Server to a

RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Paul E. Jones
But it does clue one in immediately to the fact that the parameter is non-standard. Paul -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Nottingham Sent: Tuesday, March 06, 2012 11:11 PM To: Randy Bush Cc: Randall Gellens;

Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Mark Nottingham
Yes, but (as the draft tries to explain) putting this kind of metadata in a name is prone to issues, because it can change -- i.e., when a header (or other protocol element) becomes standard. On 07/03/2012, at 4:54 PM, Paul E. Jones wrote: But it does clue one in immediately to the fact

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message 201203070539.q275dmj8001...@fs4113.wdf.sap.corp, Martin Rex writes : Mark Andrews wrote: John Levine writes: In case it wasn't clear, this is an authoritative server. If this is about permitted RCODEs here http://tools.ietf.org/html/rfc1035#section-4.1.1 then an

RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Paul E. Jones
I suppose one could argue that X- should never be on the Public Internet, anyway. But they are. If we remove X-, then what will happen is developers will use names that don't have X-. Will that make things better? No. I'd argue it will make it worse. Non-standard extensions do present

RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice

2012-03-06 Thread Randall Gellens
At 1:19 AM -0500 3/7/12, Paul E. Jones wrote: I suppose one could argue that X- should never be on the Public Internet, anyway. But they are. If we remove X-, then what will happen is developers will use names that don't have X-. Will that make things better? No. I'd argue it will make

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Patrik Fältström
On 7 mar 2012, at 03:49, John R. Levine wrote: However we do have standard presentation/entry formats defined and a good front end will accept those as well. Sigh. Now we're back to people who don't do it my way are wrong, so I guess we're done. I disagree. People who don't accept the

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-06 Thread Mark Andrews
In message d468354f-be26-41d4-9f75-ea10c5189...@frobbit.se, =?iso-8859-1?Q?Pa trik_F=E4ltstr=F6m?= writes: On 7 mar 2012, at 03:49, John R. Levine wrote: However we do have standard presentation/entry formats defined and a good front end will accept those as well. Sigh. Now we're

Last Call: draft-ietf-savi-dhcp-12.txt (SAVI Solution for DHCP) to Proposed Standard

2012-03-06 Thread The IESG
The IESG has received a request from the Source Address Validation Improvements WG (savi) to consider the following document: - 'SAVI Solution for DHCP' draft-ietf-savi-dhcp-12.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on

Last Day to Purchase IETF 83 T-shirt

2012-03-06 Thread Alexa Morris
Reminder: this is your last day to order the winning IETF 83 t-shirt. T-shirts cost $15 USD and are available in a wide variety of both men's and women's sizes. Please note that you must place your order by 11pm PT on Tuesday, March 6 in order to be guaranteed a t-shirt. We may have a limited

Last Call: draft-ietf-multimob-igmp-mld-tuning-04.txt (Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks) to Informational RFC

2012-03-06 Thread The IESG
The IESG has received a request from the Multicast Mobility WG (multimob) to consider the following document: - 'Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks' draft-ietf-multimob-igmp-mld-tuning-04.txt as an Informational RFC The IESG plans to make a

Document Action: 'LISP Map-Versioning' to Experimental RFC (draft-ietf-lisp-map-versioning-09.txt)

2012-03-06 Thread The IESG
The IESG has approved the following document: - 'LISP Map-Versioning' (draft-ietf-lisp-map-versioning-09.txt) as an Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this

Document Action: 'Analysis of Stateful 64 Translation' to Informational RFC (draft-ietf-behave-64-analysis-07.txt)

2012-03-06 Thread The IESG
The IESG has approved the following document: - 'Analysis of Stateful 64 Translation' (draft-ietf-behave-64-analysis-07.txt) as an Informational RFC This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are David Harrington and

Last Call: draft-ietf-bmwg-protection-meth-09.txt (Methodology for benchmarking MPLS protection mechanisms) to Informational RFC

2012-03-06 Thread The IESG
The IESG has received a request from the Benchmarking Methodology WG (bmwg) to consider the following document: - 'Methodology for benchmarking MPLS protection mechanisms' draft-ietf-bmwg-protection-meth-09.txt as an Informational RFC The IESG plans to make a decision in the next few weeks,

Last Call: draft-snell-atompub-tombstones-15.txt (The Atom deleted-entry Element) to Proposed Standard

2012-03-06 Thread The IESG
The IESG has received a request from an individual submitter to consider the following document: - 'The Atom deleted-entry Element' draft-snell-atompub-tombstones-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.

WG Review: INtermediary-safe SIP session ID (insipid)

2012-03-06 Thread IESG Secretary
A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list

WG Action: Conclusion of Ad-Hoc Network Autoconfiguration (autoconf)

2012-03-06 Thread IESG Secretary
The Ad-Hoc Network Autoconfiguration (autoconf) working group in the Internet Area has concluded. The IESG contact persons are Jari Arkko and Ralph Droms. This working group has reached a successful termination point. We are very happy with the RFC that has been produced by the working group,

Document Action: 'Interworking LISP with IPv4 and IPv6' to Experimental RFC (draft-ietf-lisp-interworking-06.txt)

2012-03-06 Thread The IESG
The IESG has approved the following document: - 'Interworking LISP with IPv4 and IPv6' (draft-ietf-lisp-interworking-06.txt) as an Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL

Document Action: 'The Canonical Link Relation' to Informational RFC (draft-ohye-canonical-link-relation-05.txt)

2012-03-06 Thread The IESG
The IESG has approved the following document: - 'The Canonical Link Relation' (draft-ohye-canonical-link-relation-05.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Peter Saint-Andre. A URL of

Last Call: draft-ietf-fecframe-raptor-10.txt (Raptor FEC Schemes for FECFRAME) to Proposed Standard

2012-03-06 Thread The IESG
The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Raptor FEC Schemes for FECFRAME' draft-ietf-fecframe-raptor-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this

Protocol Action: 'Sieve Email Filtering: Include Extension' to Proposed Standard (draft-ietf-sieve-include-15.txt)

2012-03-06 Thread The IESG
The IESG has approved the following document: - 'Sieve Email Filtering: Include Extension' (draft-ietf-sieve-include-15.txt) as a Proposed Standard This document is the product of the Sieve Mail Filtering Language Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre.