Re: Last Call: (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
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", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words also appear in this document in lower case as plain English words, absent their normative meanings. I don't mind changing that, but ID-nits gives a warning when the text about keywords is changed and *everybody* likes to complain about that. Please talk to IESG about whether using a variant of the standard text is acceptable. I've used text like this before, and the IESG has never objected to it. One advantage with this formulation, which uses the standard 2119 text and *appends* to it, is that idnits likes it and doesn't generate a warning. Ok then. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
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: (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard - Section 4.3 says "For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if the MTA doesn't support it." There seems to be a chicken-and-egg going on here: If the MTA doesn't support the extension, how can it know not to change the priority outbound? I meant "supports the extension, but doesn't support a particular value as distinct priority level". Suggestions on how to make this clear would be appreciated. Suggest: For example, once an MTA accepts a message, the MTA MUST not change a (syntactically valid) priority value if that value is not supported by the MTA's implementation of this extension. Ok, changed. - There are lots of SHOULDs in here that might benefit from example situations in which one might deviate from the normative statement containing the SHOULD. I will review. I had some discussion with SM about some of these and argued that not all of them should be explained. But I agree that some of them need explanation. There are some that are in more need of this than others, and I know lately that I've been thanked by ADs during IESG evaluation for providing this kind of text, so it can only help where it's possible to provide it. Sure. I've asked for explanation while I was on IESG as well. - Section 11: Why use "PRI" and not "priority"? The existing set of Received clause names are lowercase words, so it seems strange to deviate. I don't mind to switching to "PRIORITY". But section 4.4 of RFC 5321 uses uppercase variants (and yes, I know they are case insensitive). I don't think I've ever seen them in the wild, which is why it caught my attention. I've changed "PRI" to "PRIORITY" in my copy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
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? Nobody is going to simply allow priorities to be set willy-nilly on mail coming from random sources outside their administrative domain. That's absurd. Agreed. However, they may be will to make bilateral arrangements with selected partners, identified by IP address or whatever, that would allow such a setting, perhaps within a restricted range of allowed values. Right. Not allowing this actually bothered me. So I've reworded to allow for that. Would such an MTA only lower the priority or do you think it might also raise it? I don't see any reason to limit it to lowering it. > Another issue is the silly prohibition against using Priority: and other header > fields to set priority levels. What if is existing site policy is in fact to > use those fields to determine message priority? (Ignoring the question of whether use of MT-Priority header field is a good thing or not for a moment.) I actually don't have a strong feeling against usage of other existing header fields. Some of the existing header fields don't have the exact semantics desired here. Well, sure. You most definitely don't want to mix in Importance or other MUA level priority fields. Others (like the MIXER's Priority) have the right semantics but don't support sufficient number of priorities required by MMHS (6 levels). I think you're going to have to accept the fact that the overwhelming majority of people out there running email systems have never even heard of MMHS and even if they have don't give a damn about faithfully retaining it's semantics. But they do care that new mechanism be made compatible with whatever ad-hoc scheme they are currently using, even if said scheme doesn't have the full range of values. For example, I can easily see a site wanting to map this to and from the field used by Microsoft Exchange (sorry, I forget the exact name) even though if memory serves that field only accepts three values. And either this is going to happen no matter what the specification says, or the specification simply won't deploy in any meaningful way. Ok, I tend to agree. Our implementation will do this kind of mapping in absence of MT-Priority anyway. That is why a new header field was introduced. But anyway, I am happy for this restriction to be removed/relaxed. Can you recommend some specific text? I'll try to do so later this week. Is the following better: The Importance 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 header fields, such as Priority target="RFC2156"/> and X-Priority, MAY be used for determining the priority under this "Priority Message Handling" SMTP extension. ? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC
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" To: Cc: Sent: Friday, March 02, 2012 12:04 AM Subject: Re: Last Call: (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC > (2) Whether it is reasonable or appropriate for the IETF to use > our responsibility for code point assignments and consequent > relationship with IANA to try to keep protocols that are not > consistent with our design judgment and aesthetics --no matter > how grounded in experience and good engineering-- off the > Internet. That is the "Internet gatekeeper" function about > which, as you know, I've expressed concern in other contexts. I > think the answer has got to be "we can, should, and always will > exercise quality control on stable specifications and normative > references but, unless we can justify being sure of our own > infallibility, we cannot and should not try to prevent another > body from deploying a specification on the Internet by using our > control of the registration model". Telling people why we > think their ideas are sub-optimal is fine, as is identifying any > risks we see in appropriate and visible places, but telling > another group what they can't do because the IETF doesn't like > the idea isn't. We claim ownership of the name space on behalf of all parties, all SDOs governments, NGOs, anyone and anything, and this gives us a special responsibility to exercise that wisely. We should beware of imposing our ideas of correctness of any kind on another SDO - that is up to them to decide, not us. Of course, one open technical solution to a problem is best but the RFC Series is suitable cluttered with instances of the IETF failing to achieve that so any argument based on those grounds is hypocritical. A stable, approved reference is ideal, but we have been told of the widespread deployment of this approach using an experimental code point so the running code very much exists. If that is camping on something that it would be better if it were not, then that is something to fix, and something we can fix. There is no reason not to approve the allocation of a code point and furthermore, I believe we should do it now, to facilitate the migration of the existing boxes to an approved solution. If that leaves another SDO with an incompatability between what is working and what their documents say, well, the IETF has been there too; not a good place to be, but it is up to the SDO to resolve that, not the IETF. Tom Petch > And I think that distinction is entirely consistent with Russ's > suggestion. > > best, >john > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC
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, all SDOs > governments, NGOs, anyone and anything, and this gives us a special > responsibility to exercise that wisely. We should beware of imposing > our ideas of correctness of any kind on another SDO - that is up to > them to decide, not us. Our responsibility is to ourselves first and foremost, and to see that our process is followed. That process exists to, amongst other things, insure safe use and interoperable use of our own protocols. Here the process for approval of a codepoint calls for IETF review. That is this. IETF Review is defined as follows in RFC-5226: IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. In addition, we have spoken on what it means for other SDOs to request code points in RFC-4775 Section 3.2, which says, in part: Experience shows that the importance of this is often underestimated during extension design; designers sometimes assume that a new codepoint is theirs for the asking, or even simply for the taking. This is hazardous; it is far too likely that someone just taking a protocol value will find that the same value will later be formally assigned to another function, thus guaranteeing an interoperability problem. Our processes direct us to consider a codepoint assignment in this light. Finally: > > There is no reason not to approve the allocation of a code point The purpose of this review is to determine whether or not there is reason *not* to approve. Others disagree with you. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Mark Andrews 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 verification? Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth, Biscay: Variable 4, becoming west 5 to 7. Moderate or rough. Rain or showers. Good, occasionally poor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Add a link to the HTML version in i-d-announce mails ?
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 also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? Cheers, Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 only one. Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? ... +1000 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 version of the draft. I can not believe I'm the only one. Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? ... +1000 +INT_MAX Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 (perhaps those submitted along with XML?), but they're sure easier to read than TXT. Yoav On Mar 6, 2012, at 3:41 PM, 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 only one. > > Hence, would it be possible to also include a link like > http://tools.ietf.org/html/draft-name in the mail of the announced > draft? > > Cheers, > Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
On Tue, Mar 6, 2012 at 2:53 PM, Simon Perreault 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 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 also include a link like >>> http://tools.ietf.org/html/draft-name in the mail of the announced >>> draft? >>> ... >> >> >> +1000 > > > +INT_MAX +\aleph_0 :-) Seriously, it would be really nice to have this feature. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 don't know which drafts get this version (perhaps those submitted along with XML?), but they're sure easier to read than TXT. Indeed I'd like to understand that as well. In particular, as this apparently runs an outdated version of rfc2629.xslt, and then mangles it's output (HTML tidy maybe?) causing what's served to be invalid HTML. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
+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. I can not believe I'm the only one. Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? Cheers, Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 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 also include a link like > http://tools.ietf.org/html/draft-name in the mail of the announced > draft? > > Cheers, > Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
> 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , Tony F inch writes: > Mark Andrews 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 verification? > > Tony. Most front ends want to make sure what they are feeding to the back ends wont make it choke. It also make for a better user experience. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
> Is the following better: > > The Importance 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 header fields, such as Priority > and X-Priority, > MAY be used for determining the priority under this "Priority Message > Handling" SMTP extension. > What I don't like about that are: 1. It forbids using Importance, but doesn't say *why*, which could invite misuse of other similar fields that are floating around. 2. I think MAY is fine for MSAs, but too weak for MTAs. I accept what Ned says, that MTAs will do this regardless of what we say. That can argue against MUST NOT, but I think SHOULD NOT is appropriate. I think the *standard* does want to discourage it, even while accepting that it will happen. I'd still like to wait for Ned's version of some text. While we wait, let me alter my earlier proposal and re-propose it here: Other message header fields, such as "Importance" [RFC2156], "Priority" [RFC2156] and "X-Priority", are used inconsistently and often with different semantics from MT-Priority. Fields, such as "Importance", that are used to show a sense of importance to the end user are particularly ill-suited to convey transport priority, as these are distinct aspects of a message. Fields used inconsistently, such as "X-Priority", are problematic in this regard: we don't know what the intent was when the field was added. Therefore: 1. Message header fields that have a sense of showing importance to the end user MUST NOT be used to determine the priority under this SMTP extension. 2. Message Submission Agents [RFC6409] MAY use other header fields that have a sense of transport priority in order to assign an initial priority in the absence of an SMTP PRIORITY parameter. 3. Message Transfer Agents handling messages after submission SHOULD NOT use any field other than MT-Priority to determine the priority under this SMTP extension. Are we getting close? Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
On Tue, Mar 6, 2012 at 3:24 PM, Randy Bush 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, this latter maybe is more flexible (at the expense of one more click, which is negligible) > then we can each have our cake and eat it too. but i fear folk may just > want the bright shiny. > > randy > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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: 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 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 also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? Cheers, Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 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.
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.
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 issue.
Problem is then in "P" and "Q".
I personally don't see a big problem with "Q", but others clearly do so
we need to leave it in.
I'm not aware of problems, but I don't use Windows which is where the
problems are supposed to be.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 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? > > 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 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 also include a link like >> http://tools.ietf.org/html/draft-name in the mail of the announced >> draft? >> >> Cheers, >> Xavier > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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. > 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 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? >> >> 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 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 also include a link like >>> http://tools.ietf.org/html/draft-name in the mail of the announced >>> draft? >>> >>> Cheers, >>> Xavier >> > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > Scanned by Check Point Total Security Gateway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
>> 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 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.
>> 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.
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 issue.
>> Problem is then in "P" and "Q".
>
> I personally don't see a big problem with "Q", but others clearly do so
> we need to leave it in.
I'm not aware of problems, but I don't use Windows which is where the
problems are supposed to be.
Exactly - neither do I. (Well, OK, I have a Windows laptop at work to handle
the company HR stuff that won't work in anything other than IE, but I try
really, really hard never to use it.)
Ned
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Add a link to the HTML version in i-d-announce mails ?
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 believe I'm the only one. 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/ and, depending on the setting in the options page, will redirect to the Tools or Datatracker. So, if I follow a link like http://www.ietf.org/id/draft-ietf-idr-as0-03.txt the extension will notice and rewrite it to http://tools.ietf.org/html/draft-ietf-idr-as0-03 (or https://datatracker.ietf.org/doc/draft-ietf-idr-as0/ ). This is my first extension/ javascript, and it's not particularity polished, etc but if folk are interested it is on the tools page ( http://tools.ietf.org/ ) or, direct: https://chrome.google.com/webstore/detail/aiccdpabeagpjcebilebhlifplfkinao Share and enjoy. W > > Hence, would it be possible to also include a link like > http://tools.ietf.org/html/draft-name in the mail of the announced > draft? > > Cheers, > Xavier > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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, most likely by the same author(s). > > There are some false equivalences floating around here. I don't > think anyone is suggesting that having provisioning systems or even > DNS servers themselves check for syntax errors in the contents of > complex records like DKIM, SPF, DMARC, or whatever is necessarily a > bad idea. (Whether or not it will actually happen is another > matter; I'm dubious.) > > Rather, the issue is with requiring it to happen in order to deploy > a new RRTYPE of this sort, which is the result you get if the DNS > server returns some series of tokens instead of the original text > string. That's the sort of thing that forces people to upgrade, or > search around for a script to do the conversion (which won't even > occur to some), and that's an extra burden we don't need to > impose. It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. >> Why is it important what the DNS manager cares about? > > Speaking as a DNS manager myself, I care a lot about being forced > to upgrade. Upgrades bring unwanted bugs in other areas. (I'd be surprised if bugs in any area were wanted ;-) The issue is to upgrade once rather than on each new RR type. > In fact I'm not entirely thrilled with the idea of plugins to do > some extra syntax. More code means more possibilities of bugs. I'd > actually prefer to see more cross-checking of existing stuff - less > code and greater benefit. Depending on how the plugin mechanism is engineered, code insulation, data encapsulation, and component tests against large samples of data may help reduce bugs. To me, an important point is that zone files keep containing data "source", rather than the output of possibly unreproducible commands. Diagnostic-mode execution of the plugin together with a text-based /etc/rrtypes may even allow to mechanically build GUI dialogs for each type, whether for the web or for the desktop. >> Parsers, including null parsers, would come with the same >> sub-package that enables the new RR type definition. Their >> complexity would only matter to the people who read/maintain >> their sources. > > I'm sorry, but you're being naive about this. Complexity does > matter to the people who just use software because added complexity > translates to more bugs. Correct, but when you publish a complex record you are calling forth that complexity. I don't see much difference if the bug is at mines or at the remote site, since their effects are comparable. Generating zone files full of hex escapes, so as to do without any plugin, can --perhaps should-- stay possible. However, I doubt that such usage would result in less bugs, on average. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC
- Original Message - From: "Eliot Lear" To: "t.petch" Cc: "John C Klensin" ; ; 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 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, all SDOs > > governments, NGOs, anyone and anything, and this gives us a special > > responsibility to exercise that wisely. We should beware of imposing > > our ideas of correctness of any kind on another SDO - that is up to > > them to decide, not us. > > Our responsibility is to ourselves first and foremost, and to see that > our process is followed. That process exists to, amongst other things, > insure safe use and interoperable use of our own protocols. Which, Eliot, is where we part company. Given the interest in and uptake of MPLS outside the original definition, we have a wider responsibility, as we have in, say, managing the IP address or domain name space. As with the last two, if we do not consider the needs of all parties, and not just ourselves, we may lose our influence in these matters. Yes we must follow our processes but in the interests of a wider community than just ourselves. Tom Petch > > Here the process for approval of a codepoint calls for IETF review. > That is this. IETF Review is defined as follows in RFC-5226: > > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. > > In addition, we have spoken on what it means for other SDOs to request > code points in RFC-4775 Section 3.2, which says, in part: > > >Experience shows that the importance of this is often underestimated >during extension design; designers sometimes assume that a new >codepoint is theirs for the asking, or even simply for the taking. >This is hazardous; it is far too likely that someone just taking a >protocol value will find that the same value will later be formally >assigned to another function, thus guaranteeing an interoperability >problem. > > > Our processes direct us to consider a codepoint assignment in this > light. Finally: > > > > > > There is no reason not to approve the allocation of a code point > > The purpose of this review is to determine whether or not there is > reason *not* to approve. Others disagree with you. > > > Eliot > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
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, unfortunately, can't be seen publicly because of a limitation in the datatracker; perhaps I should post it here). I'm interested in hearing whether others share this concern, and what the community consensus is about it. I have no problem logging stuff from the SMTP session into a message header, we've been doing that since forever. But I have a lot of problem turning a header back into SMTP for a subsequent relay, for two reasons. One is just that it's ugly. There were good reasons to separate the envelope from the body back in the 1970s, and I think those reasons are just as good now. Over in the EAI group, there was a valiant effort to tunnel EAI messages through non-EAI SMTP servers via downgrades, and we eventually gave up. Now, if you want to send an EAI message, there has to be an EAI path all the way from the sender to the recipient. This isn't exactly analogous, but it's instructive. The other reason is that I think it's too ill-specified to interoperate. The theory seems to be that the relay server notices an MT-Priority: header, and (vigorous waving of hands) somehow decides if the message has sufficient virtue to promote the header back into the SMTP session. The hand-waving is not persuasive; the suggestion of S/MIME, which obviously won't work, is not encouraging. Both good points. While I personally am indifferent to header modification being an issue - I believe we've long since crossed that bridge - I will also note that simply changing this proposal to always insert the MT-Priority: field at submission time and leave it unchanged throughout message transit would leave most of the functionality intact and eliminate the header modification issue entirely. But the upleveling of header to envelope would remain. John is quite correct in his assertion that these are mostly uncharted waters: The only remotely comparable case I can think of is the mapping of some X.400 fields to the NOTARY extension, but in that case the mapping was from X.400 envelope material to SMTP envelope material. Additionally, the mapping was precisly specified with no wiggle room for "site policy". +1 And there's another issue, I think. As there is 'upleveling of header to envelope', the draft also describes the reverse process. In par. 4.4 an SMTP client that talks to a non-confirming SMTP server MUST add it's own MT-Priority header with a priority determined by the process described in par. 4.2. This means an MTA can receive a mail with priority determined by envelope information and sends the message using header information. Those of us who wrote SMTP client software are in a better position to comment on this than I am. But having dealt with different MTA's it strikes me as fairly unusual for an SMTP client to add headerlines to the message-in-transit at such a late stage during transmission of the message to the SMTP server. /rolf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
John R. Levine 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. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames: Variable, becoming southwest, 4, increasing 6 to gale 8. Slight or moderate, occasionally rough later. Showers, rain later. Good, occasionally poor later. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 also not required to interoperate, as the wire format queries and responses are. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: tsv-dir review of draft-garcia-shim6-applicability-03
> -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 draft-garcia-shim6-applicability-03 > > 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'; albe...@it.uc3m.es > | Asunto: tsv-dir review of draft-garcia-shim6-applicability-03 > | > | I have reviewed this document as part of the transport area > directorate's > | ongoing effort to review key IETF documents. These comments were > written > | primarily for the transport area directors, but are copied to the > document's > | authors for their information and to allow them to address any > issues > | raised. When done at the time of IETF Last Call, the authors should > consider > | this review together with any other last-call comments they receive. > Please > | always CC tsv-...@ietf.org if you reply to or forward this review. > | > | This draft is basically ready for publication, but has nits that > should > be fixed > | before publication. > | > | > | > | Nits: > | > | Section 1: > | > | Such problems are not specific of Shim6, but > | are suffered by the hosts of any site which is connected to > multiple > | transit providers, and which receives an IPv6 prefix from each of > the > | providers. > | > | It might be useful to add a non-normative reference to RFC5220 at > the end > | of that sentence. > Ok > > | > | > | Section 3.4: > | > | The use of HBA is more efficient in the sense that addresses > require > | less computation than CGA, involving only hash operations for > both > | the generation and the verification of locator sets. However, > the > | locators of an HBA set are determined during the generation > process, > | and cannot be subsequently changed; the addition of new locators > to > | that initial set is not supported, except by re-generation of the > | entire set which will in turn cause all addresses to change. > | > | I think that paragraph is too harsh, as it implies the old addresses > have > to be > | invalidated immediately. I expect existing connections could > continue > with > | the old addresses, and, if the host wanted to, could even have new > | connections use the old addresses. If that is not possible, the > draft > should > | explain why. If that is possible, the draft should probably explain > it > is > | possible. > | > > I have rewritten the paragraph: > >"The use of HBA is more efficient in the sense that addresses > require >less computation than CGA, involving only hash operations for both >the generation and the verification of locator sets. However, the >locators of an HBA set are determined during the generation process, >and cannot be subsequently changed; the addition of new locators to >that initial set is not supported. Therefore, a node using an HBA > as >ULID for a Shim6 session can only use the locators associated to > that >HBA for the considered Shim6 session. If the node wants to use a > new >set of locators, it has to generate a new HBA including the prefixes >of the new locators (which will result with very high probability in >different addresses to those of the previous set). New sessions >initiated with a ULID belonging to the new HBA address set could use >the new locators." > > Do you think it is now more clear? Yes, thanks. > | > | Section 4: > | > | In order to configure source and destination address selection, > tools > | such as DHCPv6 can be used to disseminate a [RFC3484] policy > table to > | a host. > | > | It might be useful to add a non-normative reference to draft-ietf- > 6man- > | addr-select-opt. > Sure > > | > | > | Section 4: > | > | The sentence ending with "properties exhibited by REAP." needs a > reference > | to RFC5544, which seems to be the RFC defining REAP. > Ok > > | > | > | > | Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by > the > | Shim6 node knowing its IPv6 address after NPTv6 translation. > Probably > not > | worth adjusting the document, though, as NPTv6 is experimental. > > Well, this would not work for HBA, since in this case the addresses are > fixed once generated. NPTv6 does not change the host portion of the address (it only changes the network portion -- the IPv6 prefix), so HBA should work with NPTv6. > It could work for the CGA, since the Shim6 host could sign dynamically > the > translated address. But in this case a protocol would be needed to > convey > the translated address to the Shim6 n
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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.
>
> 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 issue.
Hm... I have no idea how such response gets cached. RFC 2136 says
that "an appropriate error will be returned to the requestor's caller"
when RCODE is SERVFAIL or NOTIMP.
Is that the same case that Scott noticed when he wrote:
Particularly when querying for SPF records of type SPF, persistent
2 ServFail results are /not rare/.
http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html
(emphasis added)
?
IIRC there was also a mirroring issue...
At least, I think these issues will gradually vanish as the software
at the relevant servers gets upgraded.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 this area, and if I remember correctly,
> >> received no response.
> >
> > 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 issue.
>
> Hm... I have no idea how such response gets cached. RFC 2136 says
> that "an appropriate error will be returned to the requestor's caller"
> when RCODE is SERVFAIL or NOTIMP.
>
> Is that the same case that Scott noticed when he wrote:
>
>Particularly when querying for SPF records of type SPF, persistent
>2 ServFail results are /not rare/.
>
>http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html
>(emphasis added)
> ?
>
> IIRC there was also a mirroring issue...
>
> At least, I think these issues will gradually vanish as the software
> at the relevant servers gets upgraded.
I don't think it's the same. It's been awhile since I had data because I
simply stopped doing any type SPF queries in software I use or support due to
issues with it (and there's no upside to go expend effort on revisiting the
issue), but these were definitely SERVFAIL and not NOTIMP, but either would
have had the same effect of a permanent "temporary error".
Scott K
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
> 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 https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (The Atom "deleted-entry" Element) to Proposed Standard
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: > - 'The Atom "deleted-entry" Element' >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 substantive comments to the > ietf@ietf.org mailing lists by 2012-04-03. Exceptionally, comments may be > sent to i...@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > >This specification adds mechanisms to the Atom Syndication Format >which publishers of Atom Feed and Entry documents can use to >explicitly identify Atom entries that have been removed. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: INtermediary-safe SIP session ID (insipid)
> 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 able to search for these things in Google (or Bing, or whatever), and we've had (minor) problems in the past when working groups have had very cutesy names that have amusement value, but don't do well in web searches. "lemonade" comes to mind, and there are others. Let me encourage you to choose something other than "insipid". That said, let me encourage you not to waste very much time on this point. Barry > -- > Status: Proposed Working Group > Last Updated: 2012-03-01 > > Chairs: > TBD > > Real-Time Applications and Infrastructure Area Directors: > Gonzalo Camarillo > Robert Sparks > > Real-Time Applications and Infrastructure Area Advisor: > Gonzalo Camarillo > > Mailing Lists: > General Discussion: TBD > To Subscribe: TBD > Archive: TBD > > An end-to-end session identifier in SIP-based multimedia > communication networks refers to the ability for endpoints, > intermediate devices, and management and monitoring system to > identify and correlate SIP messages and dialogs of the same > higher-level end-to-end "communication session" across multiple > SIP devices, hops, and administrative domains. Unfortunately, > there are a number of factors that contribute to the fact that > the current dialog identifiers defined in SIP are not suitable > for end-to-end session identification. Perhaps the most important > factor worth describing is that in real-world deployments of > Back-to-Back User Agents (B2BUAs) devices like Session Border > Controllers (SBC) often change the call identifiers (e.g., the > From-tag and To-tag that are used in conjunction with the Call-ID > header to make the dialog-id) as the session signaling passes > through. > > An end-to-end session identifier should allow the possibility to > identify the communication session from the point of origin, > passing through any number of intermediaries, to the ultimate > point of termination. It should have the same aim as the > From-tag, To-tag and Call-ID conjunction, but should not be > mangled by intermediaries. > > A SIP end-to-end session identifier has been considered as possible > solution of different use cases like troubleshooting, billing, session > tracking, session recording, media and signaling correlation, and so > forth. Some of these requirements come from other working groups > within the RAI area (e.g., SIPRec). Moreover, other standards > organizations have identified the need for SIP and H.323 to carry the > same "session ID" value so that it is possible to identify a call > end-to end even when performing inter working between protocols. > > This group will focus on a document that will specify an SIP > identifier that have the same aim as the From-tag, To-tag and Call-ID > conjunction, but is less likely to be mangled by intermediaries. In > doing this work, the group will pay attention to the privacy > implications of a "session ID", for example considering the > possibility to make it intractable for nodes to correlate "session IDs" > generated by the same user for different sessions. > > Goal and Milestone: > > Dec 2012 - Specification of the new identifier sent to the IESG (PS) > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Add a link to the HTML version in i-d-announce mails ?
> -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 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 also include a link like > http://tools.ietf.org/html/draft-name in the mail of the announced > draft? ...or a link to the datatracker page, which in turn has links to all available formats? -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Add a link to the HTML version in i-d-announce mails ?
> -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 link to the datatracker HTML version: > https://datatracker.ietf.org/doc/draft-name/ > > Would this meet your needs? Serves me right for not reading the thread before replying. +ULONG_MAX, so there. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: tsv-dir review of draft-garcia-shim6-applicability-03
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'; albe...@it.uc3m.es | Asunto: tsv-dir review of draft-garcia-shim6-applicability-03 | | I have reviewed this document as part of the transport area directorate's | ongoing effort to review key IETF documents. These comments were written | primarily for the transport area directors, but are copied to the document's | authors for their information and to allow them to address any issues | raised. When done at the time of IETF Last Call, the authors should consider | this review together with any other last-call comments they receive. Please | always CC tsv-...@ietf.org if you reply to or forward this review. | | This draft is basically ready for publication, but has nits that should be fixed | before publication. | | | | Nits: | | Section 1: | | Such problems are not specific of Shim6, but | are suffered by the hosts of any site which is connected to multiple | transit providers, and which receives an IPv6 prefix from each of the | providers. | | It might be useful to add a non-normative reference to RFC5220 at the end | of that sentence. Ok | | | Section 3.4: | | The use of HBA is more efficient in the sense that addresses require | less computation than CGA, involving only hash operations for both | the generation and the verification of locator sets. However, the | locators of an HBA set are determined during the generation process, | and cannot be subsequently changed; the addition of new locators to | that initial set is not supported, except by re-generation of the | entire set which will in turn cause all addresses to change. | | I think that paragraph is too harsh, as it implies the old addresses have to be | invalidated immediately. I expect existing connections could continue with | the old addresses, and, if the host wanted to, could even have new | connections use the old addresses. If that is not possible, the draft should | explain why. If that is possible, the draft should probably explain it is | possible. | I have rewritten the paragraph: "The use of HBA is more efficient in the sense that addresses require less computation than CGA, involving only hash operations for both the generation and the verification of locator sets. However, the locators of an HBA set are determined during the generation process, and cannot be subsequently changed; the addition of new locators to that initial set is not supported. Therefore, a node using an HBA as ULID for a Shim6 session can only use the locators associated to that HBA for the considered Shim6 session. If the node wants to use a new set of locators, it has to generate a new HBA including the prefixes of the new locators (which will result with very high probability in different addresses to those of the previous set). New sessions initiated with a ULID belonging to the new HBA address set could use the new locators." Do you think it is now more clear? | | Section 4: | | In order to configure source and destination address selection, tools | such as DHCPv6 can be used to disseminate a [RFC3484] policy table to | a host. | | It might be useful to add a non-normative reference to draft-ietf-6man- | addr-select-opt. Sure | | | Section 4: | | The sentence ending with "properties exhibited by REAP." needs a reference | to RFC5544, which seems to be the RFC defining REAP. Ok | | | | Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by the | Shim6 node knowing its IPv6 address after NPTv6 translation. Probably not | worth adjusting the document, though, as NPTv6 is experimental. Well, this would not work for HBA, since in this case the addresses are fixed once generated. It could work for the CGA, since the Shim6 host could sign dynamically the translated address. But in this case a protocol would be needed to convey the translated address to the Shim6 node which has to sign it. A threat analysis of this operation should be performed, in order not to introduce new vulnerabilities in the process... As you suggest, I think this is not worth. | | | Section 7.7: | | Note that an Application Level Gateway designed to modify the Shim6 | control packets would not be able to generate a valid signature, in | case a CGA is being used, or a Parameter Data Structure binding the | translated locator to the other locators of a node, in case a HBA is | being used. Therefore, the same failure cases described before would | remain. | | Applications are layer 7, Shim6 is layer 3, so an "Application Layer Gateway" | that modifies Shim6 control packet
Re: Add a link to the HTML version in i-d-announce mails ?
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 beloved permathread. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
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 HTML is better. > > But I fear we're getting close to our beloved permathread. Pictures in RFCs? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "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 imply they are > > implementation-specific. > > 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. The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn't want to support a name server. The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded. > Regards, > John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
> 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
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 in other ways, ranging from djbdns mutant syntax text files to various databases. Whatever the server uses, the provisioning system better match. The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn't want to support a name server. The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded. That is one implementation. But it's far from the only one. My system has a web front end that lets my users edit groups of their djbdns RRs, which it stores in a database. Once an hour, a perl script goes through the database, regenerates the mutant text files, and stuffs them into the name servers. It's not fabulous, but it gets the job done. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
On 3/1/12 5:14 PM, Scott Kitterman wrote: > > > Peter Saint-Andre 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 following document: - 'Deprecating Use of the "X-" Prefix in Application Protocols' as a Best Current Practice The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send substantive comments to >> the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments >> may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or >> similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the "X-" convention for textual parameters in application protocols. >>> ... >>> >>> 2. Recommendations for Implementers of Application Protocols >>> >>>Implementers of application protocols MUST NOT treat the general >>>categories of "standard" and "non-standard" parameters in >>>programatically different ways within their applications. >>> >>> Shouldn't this restrict itself to the naming of parameters? Perhaps: >>> >>> 2. Recommendations for Implementers of Application Protocols >>> >>>Implementers of application protocols MUST NOT treat the general >>>naming of parameters in programmatically different ways within >>>their applications depending on if they are "standard" or >> "non-standard". >> >> How about this? >> >> Implementations of application protocols MUST NOT programatically >> discriminate between "standard" and "non-standard" parameters based >> solely on the names of such parameters. > > I'm not quite sure. > > Is this supposed to be about how one selects names or how one uses them. I'd > thought it meant the former, but your revised text sounds like the latter to > me. The concept behind this text was always about how one uses names, or more precisely how code implementations treat them, because the authors are of the opinion that it's a bad idea for implementations to hardcode their handling of parameter based solely on the existence of the string 'x-' at the start of the parameter name. I think the revised text I provided captures this more clearly. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 in this area, and if I remember correctly,
> >> received no response.
> >
> > 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 issue.
>
> Hm... I have no idea how such response gets cached. RFC 2136 says
> that "an appropriate error will be returned to the requestor's caller"
> when RCODE is SERVFAIL or NOTIMP.
>
> Is that the same case that Scott noticed when he wrote:
>
>Particularly when querying for SPF records of type SPF, persistent
>2 ServFail results are /not rare/.
>
>http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html
>(emphasis added)
> ?
>
> IIRC there was also a mirroring issue...
>
> At least, I think these issues will gradually vanish as the software
> at the relevant servers gets upgraded.
A RFC 1035 recursive server should be able to handle SPF. It's
just a opaque data blob to it with a name, type, class and ttl
attributes. To serve SPF a RFC 1035 needed to be upgraded as it had
no way to store / load the record.
DNS software developers should read Section 3.6. "Defining new types,
classes, and special namespaces", especially the sentence:
New definitions should be expected.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 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 following document: > - 'Deprecating Use of the "X-" Prefix in Application Protocols' > > as a Best Current Practice > > The IESG plans to make a decision in the next few weeks, and > >> > >> solicits > >> > final comments on this action. Please send substantive comments to > >> > >> the > >> > ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments > >> > >> may be > >> > sent to i...@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > Historically, designers and implementers of application > protocols > have often distinguished between "standard" and > "non-standard" > parameters by prefixing the latter with the string "X-" or > >> > >> similar > >> > constructions. In practice, this convention causes more > problems > than it solves. Therefore, this document deprecates the > "X-" > convention for textual parameters in application protocols. > >>> > >>> ... > >>> > >>> 2. Recommendations for Implementers of Application Protocols > >>> > >>>Implementers of application protocols MUST NOT treat the > >>>general > >>>categories of "standard" and "non-standard" parameters in > >>>programatically different ways within their applications. > >>> > >>> Shouldn't this restrict itself to the naming of parameters? > >>> Perhaps: > >>> > >>> 2. Recommendations for Implementers of Application Protocols > >>> > >>>Implementers of application protocols MUST NOT treat the > >>>general > >>>naming of parameters in programmatically different ways within > >>>their applications depending on if they are "standard" or > >> > >> "non-standard". > >> > >> How about this? > >> > >> Implementations of application protocols MUST NOT programatically > >> discriminate between "standard" and "non-standard" parameters > >> based > >> solely on the names of such parameters. > > > > I'm not quite sure. > > > > Is this supposed to be about how one selects names or how one uses them. > > I'd thought it meant the former, but your revised text sounds like the > > latter to me. > The concept behind this text was always about how one uses names, or > more precisely how code implementations treat them, because the authors > are of the opinion that it's a bad idea for implementations to hardcode > their handling of parameter based solely on the existence of the string > 'x-' at the start of the parameter name. I think the revised text I > provided captures this more clearly. Yes. Thanks for clarifying. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 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 following document: >> - 'Deprecating Use of the "X-" Prefix in Application Protocols' >> >>as a Best Current Practice >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be >> sent to i...@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >>Historically, designers and implementers of application >>protocols >>have often distinguished between "standard" and >>"non-standard" >>parameters by prefixing the latter with the string "X-" or similar >>constructions. In practice, this convention causes more >>problems >>than it solves. Therefore, this document deprecates the >>"X-" >>convention for textual parameters in application protocols. > > ... > > 2. Recommendations for Implementers of Application Protocols > >Implementers of application protocols MUST NOT treat the >general >categories of "standard" and "non-standard" parameters in >programatically different ways within their applications. > > Shouldn't this restrict itself to the naming of parameters? > Perhaps: > > 2. Recommendations for Implementers of Application Protocols > >Implementers of application protocols MUST NOT treat the >general >naming of parameters in programmatically different ways within >their applications depending on if they are "standard" or "non-standard". How about this? Implementations of application protocols MUST NOT programatically discriminate between "standard" and "non-standard" parameters based solely on the names of such parameters. >>> >>> I'm not quite sure. >>> >>> Is this supposed to be about how one selects names or how one uses them. >>> I'd thought it meant the former, but your revised text sounds like the >>> latter to me. >> The concept behind this text was always about how one uses names, or >> more precisely how code implementations treat them, because the authors >> are of the opinion that it's a bad idea for implementations to hardcode >> their handling of parameter based solely on the existence of the string >> 'x-' at the start of the parameter name. I think the revised text I >> provided captures this more clearly. > > Yes. Thanks for clarifying. Thanks for requesting clarification. 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., based solely on whether the name begins with 'x-' or a similar string of characters). Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 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 following document: > >> - 'Deprecating Use of the "X-" Prefix in Application > >> Protocols' > >> > >>as a Best Current > >> Practice > >> > >> The IESG plans to make a decision in the next few weeks, and > > solicits > > >> final comments on this action. Please send substantive > >> comments to > > the > > >> ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, > >> comments > > may be > > >> sent to i...@ietf.org instead. In either case, please retain > >> the > >> beginning of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >>Historically, designers and implementers of application > >>protocols > >>have often distinguished between "standard" and > >>"non-standard" > >>parameters by prefixing the latter with the string "X-" > >>or > > similar > > >>constructions. In practice, this convention causes more > >>problems > >>than it solves. Therefore, this document deprecates the > >>"X-" > >>convention for textual parameters in application > >>protocols. > > > > ... > > > > 2. Recommendations for Implementers of Application Protocols > > > >Implementers of application protocols MUST NOT treat the > >general > >categories of "standard" and "non-standard" parameters in > >programatically different ways within their applications. > > > > Shouldn't this restrict itself to the naming of parameters? > > Perhaps: > > > > 2. Recommendations for Implementers of Application Protocols > > > >Implementers of application protocols MUST NOT treat the > >general > >naming of parameters in programmatically different ways > >within > >their applications depending on if they are "standard" or > > "non-standard". > > How about this? > > Implementations of application protocols MUST NOT > programatically > discriminate between "standard" and "non-standard" parameters > based > solely on the names of such parameters. > >>> > >>> I'm not quite sure. > >>> > >>> Is this supposed to be about how one selects names or how one uses > >>> them. I'd thought it meant the former, but your revised text sounds > >>> like the latter to me. > >> > >> The concept behind this text was always about how one uses names, or > >> more precisely how code implementations treat them, because the > >> authors > >> are of the opinion that it's a bad idea for implementations to > >> hardcode > >> their handling of parameter based solely on the existence of the > >> string > >> 'x-' at the start of the parameter name. I think the revised text I > >> provided captures this more clearly. > > > > Yes. Thanks for clarifying. > > Thanks for requesting clarification. > > 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., based solely on >whether the name begins with 'x-' or a similar string of characters). > > Peter Looks good to me. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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., based solely on whether the name begins with 'x-' or a similar string of characters). I like this wording, especially because it more clearly gets at the heart of the document, which is to not discriminate based only on the name prefix. One question, though: should this be "SHOULD NOT" rather than "MUST NOT"? The interoperability doesn't depend on implementations refraining from doing so, rather, we consider it more problematic to do so than not, so we are making a strong recommendation to not to so. Hence, "SHOULD NOT". From RFC 2119: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- Language is a virus from outer space. --William S. Burroughs ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
Not that voicing opinions on this topic has ever done any good. -T On Tue, Mar 6, 2012 at 2:15 PM, Russ Housley wrote: > >> 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 >> solely on the names of such parameters (i.e., based solely on >> whether the name begins with 'x-' or a similar string of characters). > > I like this wording, especially because it more clearly gets at the > heart of the document, which is to not discriminate based only on the > name prefix. > > One question, though: should this be "SHOULD NOT" rather than "MUST > NOT"? The interoperability doesn't depend on implementations > refraining from doing so, rather, we consider it more problematic to do > so than not, so we are making a strong recommendation to not to so. > Hence, "SHOULD NOT". Hi Randall, My co-author Mark Nottingham feels even more strongly about this issue than I do, so I will let him comment. However, note the existence of things like the "x-gzip" and "gzip" content codings in HTTP, which RFC 2068 says are equivalent. An implementation that programmatically discriminated between "standard" and "non-standard" parameters based solely on the parameter names might automatically reject entities for which a content-coding of "x-gzip" is specified, but automatically accept entities for which a content-coding of "gzip" is specified. IMHO that's just wrong, and MUST NOT is appropriate. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
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 too is rare, since implementers can almost always find >a synonym for an existing term (e.g., "urgency" instead of >"priority") or simply invent a more creative name (e.g., "get-it- >there-fast"). > > At the end, I suggest adding an additional sentence: > > The existence of multiple similarly-named paramaters can > be confusing, but this is true regardless if there is an > attempt to segregate standard and non-standard (e.g., > "X-Priority" can be confused with "Urgency"). True. If my co-authors agree, I'll add that to our working copy. > Second, consider this the text in Appendix B: > >Furthermore, often standardization of a non-standard parameter or >protocol element leads to subtly different behavior (e.g., the >standard version might have different security properties as a result >of security review provided during the standardization process). If >implementers treat the old, non-standard parameter and the new, >standard parameter as equivalent, interoperability and security >problems can ensue. > > This is of course true, but I think it is somewhat misleading: If a > parameter starts out as non-standard, gets some deployment, then as part > of an effort to standardize it, flaws are discovered which require > different behavior, I think we want the new, standardized parameter to > have a different name so it can be distinguished and the new, more > desirable behavior mandated. This is the same regardless if the old and > new parameters are, say, "x-priority" and "priority", or "priority" and > "urgency". In either case, implementers shouldn't treat the old > parameter as identical to the new, standardized one. Yet that's what RFC 2068 says: For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. However, as far as I have been able to determine there were no significant differences between the "standard" and "non-standard" versions of those parameters (others here would know better than I do). > Further, I think it's a good thing when an old, non-standard parameter > is standardized and flaws are corrected. We should encourage, not > discourage this. Indeed. > It would be good to have at least a little text along these lines. > Specifically, I suggest adding new text at the end: > > Analysis of non-standard parameters and protocol elements > to detect and correct flaws is in general a good thing and > is not intended to be discouraged by the lack of > distinction in element names. Whenever an originally > non-standard parameter or protocol element is standardized > and the new form has differences which affect > interoperability or security properties, implementations > MUST NOT treat the old form as identical to the new form. That seems fine (although I would not include "protocol element" because this document is only about parameters). > Further in the appendix, justification 1 is over-drawn. I suggest > toning it down slightly, from: > >1. Implementers are easily confused and can't be expected to know >that a parameter is non-standard unless it contains the "X-" >prefix. However, implementers already are quite flexible about >using both prefixed and non-prefixed names based on what works in >the field, so the distinction between de facto names (e.g., >"X-foo") and de jure names (e.g., "foo") is without force. > > To: > >1. Implementers may confuse parameters that have similar >names; a rigid distinction such as an "X-" prefix can make >this clear. However, in practice implementers are forced >to blur the distinction (e.g., by treating "X-foo" as a de >facto standard) and so it inevitably becomes meaningless. WFM, let's see if my co-authors agree. Proposed text is always appreciated. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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: (Deprecating > Use of the "X-" Prefix in Application Protocols) to Best Current > Practice > > However, note the existence of things like the "x-gzip" and "gzip" > content codings in HTTP, which RFC 2068 says are equivalent. An > implementation that programmatically discriminated between "standard" > and "non-standard" parameters based solely on the parameter names might > automatically reject entities for which a content-coding of "x-gzip" is > specified, but automatically accept entities for which a content-coding > of "gzip" is specified. IMHO that's just wrong, and MUST NOT is > appropriate. So should this document note that it "Updates 2068"? -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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: (Deprecating >> Use of the "X-" Prefix in Application Protocols) to Best Current >> Practice >> >> However, note the existence of things like the "x-gzip" and "gzip" >> content codings in HTTP, which RFC 2068 says are equivalent. An >> implementation that programmatically discriminated between "standard" >> and "non-standard" parameters based solely on the parameter names might >> automatically reject entities for which a content-coding of "x-gzip" is >> specified, but automatically accept entities for which a content-coding >> of "gzip" is specified. IMHO that's just wrong, and MUST NOT is >> appropriate. > > So should this document note that it "Updates 2068"? I don't think so, because "x-gzip" and "gzip" were in fact equivalent (as far as I can see), so treating them as equivalent seems just fine. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 between "standard" and "non-standard" parameters based solely on the names of such parameters (i.e., based solely on whether the name begins with 'x-' or a similar string of characters). I like this wording, especially because it more clearly gets at the heart of the document, which is to not discriminate based only on the name prefix. One question, though: should this be "SHOULD NOT" rather than "MUST NOT"? The interoperability doesn't depend on implementations refraining from doing so, rather, we consider it more problematic to do so than not, so we are making a strong recommendation to not to so. Hence, "SHOULD NOT". Hi Randall, My co-author Mark Nottingham feels even more strongly about this issue than I do, so I will let him comment. However, note the existence of things like the "x-gzip" and "gzip" content codings in HTTP, which RFC 2068 says are equivalent. An implementation that programmatically discriminated between "standard" and "non-standard" parameters based solely on the parameter names might automatically reject entities for which a content-coding of "x-gzip" is specified, but automatically accept entities for which a content-coding of "gzip" is specified. IMHO that's just wrong, and MUST NOT is appropriate. Hi Peter, Is the hypothetical application discriminating between all "x-" and everything else, or is it only doing so for parameters it does not recognize? In the case of "x-gzip" and "gzip", wouldn't the application be doing whatever it does based on recognizing that this is gzip? Anyway, it's hard for me to imagine a real application doing something like what the text suggests (say, bouncing email with "x-gzip" or refusing to expand an file or attachment of "x-gzip"), and even if there were such an application, 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. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- Computers are not intelligent. They only think they are. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
>> > 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 issue.
In case it wasn't clear, this is an authoritative server.
>A RFC 1035 recursive server should be able to handle SPF. It's
>just a opaque data blob to it with a name, type, class and ttl
>attributes.
Agreed. Other than a few dusty Suns still running obsolete BIND 4.x,
I don't know of any DNS caches that have problems with arbitrary RRs.
R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
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 parameter names might have significant meaning. However, this case too is rare, since implementers can almost always find a synonym for an existing term (e.g., "urgency" instead of "priority") or simply invent a more creative name (e.g., "get-it- there-fast"). At the end, I suggest adding an additional sentence: The existence of multiple similarly-named paramaters can be confusing, but this is true regardless if there is an attempt to segregate standard and non-standard (e.g., "X-Priority" can be confused with "Urgency"). True. If my co-authors agree, I'll add that to our working copy. Second, consider this the text in Appendix B: Furthermore, often standardization of a non-standard parameter or protocol element leads to subtly different behavior (e.g., the standard version might have different security properties as a result of security review provided during the standardization process). If implementers treat the old, non-standard parameter and the new, standard parameter as equivalent, interoperability and security problems can ensue. This is of course true, but I think it is somewhat misleading: If a parameter starts out as non-standard, gets some deployment, then as part of an effort to standardize it, flaws are discovered which require different behavior, I think we want the new, standardized parameter to have a different name so it can be distinguished and the new, more desirable behavior mandated. This is the same regardless if the old and new parameters are, say, "x-priority" and "priority", or "priority" and "urgency". In either case, implementers shouldn't treat the old parameter as identical to the new, standardized one. Yet that's what RFC 2068 says: For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. However, as far as I have been able to determine there were no significant differences between the "standard" and "non-standard" versions of those parameters (others here would know better than I do). Thanks for digging that up. I think this goes to my point, which is that either there are important differences, or there aren't; if there are (especially security-related ones) then we don't want to treat the old, non-standard and the new standard as equivalent, because it isn't safe to treat them as the same. But if it is safe to treat them as the same, then of course it makes sense to do so. And this is orthogonal to an attempt to segregate standard and non-standard names. I think it also makes your point, which is that the attempt at segregating the names doesn't help; we still want to either treat them as the same or not, based on specifics of the situation, not the name. I'd even suggest that this aspect is a strong argument in favor of this document: it doesn't work to use the names as an automatic discriminator, there needs to be case-by-case evaluation. > Further, I think it's a good thing when an old, non-standard parameter is standardized and flaws are corrected. We should encourage, not discourage this. Indeed. It would be good to have at least a little text along these lines. Specifically, I suggest adding new text at the end: Analysis of non-standard parameters and protocol elements to detect and correct flaws is in general a good thing and is not intended to be discouraged by the lack of > distinction in element names. Whenever an originally non-standard parameter or protocol element is standardized and the new form has differences which affect interoperability or security properties, implementations MUST NOT treat the old form as identical to the new form. That seems fine (although I would not include "protocol element" because this document is only about parameters). Sounds good to me. I only added "protocol element" because I saw it elsewhere in the document. > Further in the appendix, justification 1 is over-drawn. I suggest toning it down slightly, from: 1. Implementers are easily confused and can't be expected to know that a parameter is non-standard unless it contains the "X-" prefix. However, implementers already are quite flexible about using both prefixed and non-prefixed names based on what works in the field, so the distinction between de facto names (e.g., "X-foo") and de jure names (e.g., "foo") is without force. To: 1. Implementers may confuse parameters that have similar names; a rigid
Re: [IETF] Add a link to the HTML version in i-d-announce mails ?
> 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/ and,
> depending on the setting in the options page, will redirect to the Tools or
> Datatracker.
Inspired by that, I wrote a completely trivial (one-line) Greasemonkey
script this afternoon, to do it for Firefox. It's so short that I'll
just paste it below. Works nicely.
Barry
--
// ==UserScript==
// @name IETF draft html
// @namespace ...whatever...
// @descriptionRedirect txt drafts to html
// @includehttp://www.ietf.org/id/*
// @includehttps://www.ietf.org/id/*
// ==/UserScript==
(function () {
window.location = new
String(window.location).replace("www.ietf.org/id",
"tools.ietf.org/html").replace(".txt", "");
})();
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
> 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 would generally be considered broken if you did X, then I think that rates a MUST NOT X. It's often a bit of judgment whether to use MUST NOT or SHOULD NOT, and we have some latitude in making that judgment. I agree with PSA and MNot that this case should be MUST NOT. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 Internet is the bar for MUST. If your implementation would generally be considered broken if you did X, then I think that rates a MUST NOT X. It's often a bit of judgment whether to use MUST NOT or SHOULD NOT, and we have some latitude in making that judgment. I agree with PSA and MNot that this case should be MUST NOT. Yeah, harm to the Internet is overblown, sorry. But still, if a violation doesn't harm anyone else, then I don't think a MUST NOT is justified. My reading of 2119 is the basis for this: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- He knows nothing, and he thinks he knows everything. That points clearly to a political career. -- George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Add a link to the HTML version in i-d-announce mails ?
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/
>> and,
>> depending on the setting in the options page, will redirect to the Tools or
>> Datatracker.
>
> Inspired by that, I wrote a completely trivial (one-line) Greasemonkey
> script this afternoon, to do it for Firefox. It's so short that I'll
> just paste it below. Works nicely.
Oooh, very cool….
W
>
> Barry
>
> --
> // ==UserScript==
> // @name IETF draft html
> // @namespace ...whatever...
> // @descriptionRedirect txt drafts to html
> // @includehttp://www.ietf.org/id/*
> // @includehttps://www.ietf.org/id/*
> // ==/UserScript==
>
> (function () {
>window.location = new
> String(window.location).replace("www.ietf.org/id",
> "tools.ietf.org/html").replace(".txt", "");
> })();
> --
>
--
Don't be impressed with unintelligible stuff said condescendingly.
-- Radia Perlman.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 between "standard" and "non-standard" parameters based >>>solely on the names of such parameters (i.e., based solely on >>>whether the name begins with 'x-' or a similar string of characters). >> >> I like this wording, especially because it more clearly gets at the >> heart of the document, which is to not discriminate based only on the >> name prefix. >> >> One question, though: should this be "SHOULD NOT" rather than "MUST >> NOT"? The interoperability doesn't depend on implementations >> refraining from doing so, rather, we consider it more problematic to do >> so than not, so we are making a strong recommendation to not to so. >> Hence, "SHOULD NOT". > > Hi Randall, > > My co-author Mark Nottingham feels even more strongly about this issue > than I do, so I will let him comment. 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. Regards, -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 protocols MUST NOT programatically discriminate between "standard" and "non-standard" parameters based solely on the names of such parameters (i.e., based solely on whether the name begins with 'x-' or a similar string of characters). I like this wording, especially because it more clearly gets at the heart of the document, which is to not discriminate based only on the name prefix. One question, though: should this be "SHOULD NOT" rather than "MUST NOT"? The interoperability doesn't depend on implementations refraining from doing so, rather, we consider it more problematic to do so than not, so we are making a strong recommendation to not to so. Hence, "SHOULD NOT". Hi Randall, My co-author Mark Nottingham feels even more strongly about this issue than I do, so I will let him comment. 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. Hi Mark, The point of the draft is to say that it's a bad idea to do this or to try and have a system where this is expected. The draft does a good job at saying this. I just think a "MUST NOT" isn't warranted here; I think a "SHOULD NOT" is justified per RFC 2119. I think a "SHOULD NOT" makes the point: Doing it makes bad things happen. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- I personally think we developed language because of our deep need to complain.--Lily Tomlin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "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. But as I presume you also know, there are plenty > of DNS servers that store the zone info in other ways, ranging from djbdns > mutant syntax text files to various databases. > > Whatever the server uses, the provisioning system better match. BIND stores zones in other ways as well. You just have to be able accept them and produce them or else you don't have a comforming implementation. > > The standard format of master files allows them to be exchanged between > > hosts (via FTP, mail, or some other mechanism); this facility is useful > > when an organization wants a domain, but doesn't want to support a name > > server. The organization can maintain the master files locally using a > > text editor, transfer them to a foreign host which runs a name server, > > and then arrange with the system administrator of the name server to get > > the files loaded. > > That is one implementation. But it's far from the only one. > > My system has a web front end that lets my users edit groups of their > djbdns RRs, which it stores in a database. Once an hour, a perl script > goes through the database, regenerates the mutant text files, and stuffs > them into the name servers. It's not fabulous, but it gets the job done. Nobody says you can't have propriatry methods of data entry. However we do have standard presentation/entry formats defined and a good front end will accept those as well. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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", Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 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., based solely on >whether the name begins with 'x-' or a similar string of characters). I like this wording, especially because it more clearly gets at the heart of the document, which is to not discriminate based only on the name prefix. One question, though: should this be "SHOULD NOT" rather than "MUST NOT"? The interoperability doesn't depend on implementations refraining from doing so, rather, we consider it more problematic to do so than not, so we are making a strong recommendation to not to so. Hence, "SHOULD NOT". >>> >>> Hi Randall, >>> >>> My co-author Mark Nottingham feels even more strongly about this issue >>> than I do, so I will let him comment. >> >> 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. > > Hi Mark, > > The point of the draft is to say that it's a bad idea to do this or to try > and have a system where this is expected. The draft does a good job at > saying this. I just think a "MUST NOT" isn't warranted here; I think a > "SHOULD NOT" is justified per RFC 2119. I think a "SHOULD NOT" makes the > point: Doing it makes bad things happen. I have to disagree; MUST NOT *is* justified. Deploying systems like this causes real interoperability problems, which is in scope for a MUST NOT. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
> 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 X-? randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 a long time since I've run into anyone else like that, so I
> >> > agree, it's not an issue.
>
> In case it wasn't clear, this is an authoritative server.
A authoritative server should be returning NOERROR / NXDOMAIN not
NOTIMP provided the zone loads otherwise SERVFAIL if the load fails
for any type other than those in the reserved meta type range. If
the data isn't in the zone and the name is in use NOERROR is the
response you send. If the name isn't in use NXDOMAIN is the response
you send. Failure to load all of the zone is supposed to stop any
of it being served according to RFC 1035.
If you want to be a nameserver developer you don't stop counting
at 1035. The meta type range was initially reserved in RFC 2929
(Sep 2000).
> >A RFC 1035 recursive server should be able to handle SPF. It's
> >just a opaque data blob to it with a name, type, class and ttl
> >attributes.
>
> Agreed. Other than a few dusty Suns still running obsolete BIND 4.x,
> I don't know of any DNS caches that have problems with arbitrary RRs.
>
> R's,
> John
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 issue.
In case it wasn't clear, this is an authoritative server.
A authoritative server should be returning NOERROR / NXDOMAIN not
NOTIMP
Yes, we all know that. My point, which I would have thought was obvious,
was that it's been a long time since I've run into anyone whose server was
broken like that. As I said, it's not an issue.
R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 bat please? is there any general semantic to X-? I think one of the main points of the draft is to answer that question with "no." -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "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 of point of having standard presentation formats is that they facilitate data interchange. I can use my tools to generate the records and your system can just accept it. Having to re-format data is a pain. If you want to do something else as well there is no problem with that. It's a little like credit card numbers. Breaking them up into 4 boxes of 4 digits and having to move the focus between boxes is a absolute pain. These should be cut and pastable, with or without spaces in the middle. There are international standards for telephone numbers but every web developer seems to think they know best. > Regards, > John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
> 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 https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , 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 over it. > randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 query, authoritative or not is irrelevant, and if any client chokes on such an answer, it is likely the client that is broken. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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; ietf@ietf.org > Subject: Re: Last Call: (Deprecating Use > of the "X-" Prefix in Application Protocols) to Best Current Practice > > > 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 bat please? is there any general semantic to X-? > > > I think one of the main points of the draft is to answer that question > with "no." > > -- > Mark Nottingham http://www.mnot.net/ > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 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; ietf@ietf.org >> Subject: Re: Last Call: (Deprecating Use >> of the "X-" Prefix in Application Protocols) to Best Current Practice >> >> >> 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 bat please? is there any general semantic to X-? >> >> >> I think one of the main points of the draft is to answer that question >> with "no." >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 RCODE of 4 in the response looks like a perfectly valid response > for a DNS Server to a query, authoritative or not is irrelevant, and > if any client chokes on such an answer, it is likely the client that > is broken. No, its about what should be generated. NOTIMP != NOERROR no data. > -Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 issues, that's no in question. However, killing X- will only mean other values will be used. At least X- can be ignored. I'm not going to throw up a roadblock to the draft. Call for the end of X- if you want, but I know it will not stop introduction of non-standard values in protocols, so a problem will remain. One way to help this is to get standards through the IETF faster. Some take forever. Paul > -Original Message- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Wednesday, March 07, 2012 12:57 AM > To: Paul E. Jones > Cc: 'Randy Bush'; 'Randall Gellens'; ietf@ietf.org > Subject: Re: Last Call: (Deprecating Use > of the "X-" Prefix in Application Protocols) to Best Current Practice > > 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 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; ietf@ietf.org > >> Subject: Re: Last Call: > >> (Deprecating Use of the "X-" Prefix in Application Protocols) to Best > >> Current Practice > >> > >> > >> 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 bat please? is there any general semantic to X-? > >> > >> > >> I think one of the main points of the draft is to answer that > >> question with "no." > >> > >> -- > >> Mark Nottingham http://www.mnot.net/ > >> > >> > >> > >> ___ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > > > > -- > Mark Nottingham http://www.mnot.net/ > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice
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 it worse. Non-standard extensions do present issues, that's no in question. However, killing X- will only mean other values will be used. At least X- can be ignored. I was quite skeptical for a while, but came around to seeing the case that trying to segregate non-standard parameters ends up creating more problems than it solves. You're right that people will use names without an 'x' and the draft encourages this. So, we'll end up with (as I think the draft suggests), situations where 'priority' is the old, non-standard name, and 'urgency' is the new, standardized name, instead of 'x-priority' and 'priority'. But the fact is that names which start out as non-standard hacks end up being de facto standards. That's no better. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- We adore chaos because we love to produce order. --M. C. Escher ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 standardized zone format are wrong" is Mark's statement. What you say is "as people do not support the standardized zone format as input, what do we do". Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , =?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 back to "people who don't do it my way are wrong", so I gu > ess we're done. > > I disagree. > > "People who don't accept the standardized zone format are wrong" is Mark's st > atement. > > What you say is "as people do not support the standardized zone format as inp > ut, what do we do". > >Patrik The point of RFC 3597 was to provide a STANDARD text representation that could handle any DNS record format. It isn't pretty but as long as you accept it and emit it you are future proof. Its a lowest common format. A 1.2.3.4 == TYPE1 \# 4 01020304 Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. Pretty is for the next revision of the provisioning software. Look at what data you have in raw format and use that to decide what you need to handle in a prettier manner in the next revision. You don't even need to to change the database tables. It's just front end presentation that needs to be changed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
