Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-15 17:59, Boris Zbarsky wrote: On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote: The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. No, it's to propose abandoning normalization because it's not necessarily compatible with existing deployed uses of about:, not clearly compatible with the web security model, and because the normalization is not defined in the spec. The Gecko behavior is just an illustration of the first point. The purpose of our draft is to give a stable specification of the scheme Yes, this is fine. and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. Mykyta, we do need to make this spec document reality, particularly where implementations are unwilling to make changes. If it doesn't do that, then the spec is useless. I will be reviewing the options and look into exactly how other browsers handle these cases, and make appropriate changes to the spec. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-16 10:59, Lachlan Hunt wrote: On 2011-06-15 17:59, Boris Zbarsky wrote: On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote: The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. No, it's to propose abandoning normalization because it's not necessarily compatible with existing deployed uses of about:, not clearly compatible with the web security model, and because the normalization is not defined in the spec. The Gecko behavior is just an illustration of the first point. The purpose of our draft is to give a stable specification of the scheme Yes, this is fine. and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. Mykyta, we do need to make this spec document reality, particularly where implementations are unwilling to make changes. If it doesn't do that, then the spec is useless. I will be reviewing the options and look into exactly how other browsers handle these cases, and make appropriate changes to the spec. On the other hand, you're trying to define a URI scheme. If it's handling conflicts with the base URI spec, that's a bug. Period. You may *document* that some UAs have this bug, but you can't change it to be not a bug. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-16 11:14, Julian Reschke wrote: On the other hand, you're trying to define a URI scheme. If it's handling conflicts with the base URI spec, that's a bug. Period. You may *document* that some UAs have this bug, but you can't change it to be not a bug. Theoretical purity is not a priority for the specs I edit. Wilful violations of other specs where necessary are acceptable. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-16 11:20, Lachlan Hunt wrote: On 2011-06-16 11:14, Julian Reschke wrote: On the other hand, you're trying to define a URI scheme. If it's handling conflicts with the base URI spec, that's a bug. Period. You may *document* that some UAs have this bug, but you can't change it to be not a bug. Theoretical purity is not a priority for the specs I edit. Wilful violations of other specs where necessary are acceptable. Lachlan, with all due respect, I really do not care what *your* priorities here are. If you define a URI scheme, you'll have to be consistent with URI syntax. There's really no wiggle room except for warning about implementations that may not do it right. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
The question is what necessary means in terms of willful violations of specs. There are at least three cases I can understand, with different implications: There are cases where the existing spec, while it claims to apply, actually is a bad idea. Then we need to document the problem and the solution, and make sure the community agrees to the change. This happens. It usually results in an updates indication in the new spec, so folks know that the old one is not complete. There are cases where a spec is documenting existing practice. IIt can document that practice is different from the spec. It has to do so while carefully being clear that the standards should apply, and that the practice does not match. It is often useful to discuss the reasons for the mismatch. Then there are cases where folks are attempting to standardizea space that has been unclear, under-specified, or a mess, and much of the space does not comply with the specs. That is NOT a good reason to standardize non-compliant behavior. I can not tell which of those you mean when you say that Willful violations of other specs where necessary are acceptable. Yours, Joel On 6/16/2011 5:20 AM, Lachlan Hunt wrote: On 2011-06-16 11:14, Julian Reschke wrote: On the other hand, you're trying to define a URI scheme. If it's handling conflicts with the base URI spec, that's a bug. Period. You may *document* that some UAs have this bug, but you can't change it to be not a bug. Theoretical purity is not a priority for the specs I edit. Wilful violations of other specs where necessary are acceptable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote: Applications SHOULD resolve unrecognized about URIs in the same way as about:blank. ... I don't think MAY is fine here, as this is a recommendation. I'm questioning it being a recommendation, is the point. Why is this behavior recommended, exactly? Given lack of existing interop and lack of a MUST-level requirement here, the only reason for a SHOULD would be if the behavior is believed to be better than other alternatives, right? Is it? I don't see why. The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. No, it's to propose abandoning normalization because it's not necessarily compatible with existing deployed uses of about:, not clearly compatible with the web security model, and because the normalization is not defined in the spec. The Gecko behavior is just an illustration of the first point. The purpose of our draft is to give a stable specification of the scheme Yes, this is fine. and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. That's not clear to me given the security implications. Do you have data to back this up? Boris, could you please let me know whether you have some strong opinion regarding your January comments/insist on incorporating them in the draft. See above. -Boris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07
Thanks for the response. Comments inline. I deleted sections that appear not to need further discussion. Thanks! Ben. On Jun 14, 2011, at 2:11 PM, Cakulev, Violeta (Violeta) wrote: Ben, Thanks for the comments. Please see inline [VC]. -Violeta -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Friday, June 03, 2011 4:10 PM To: draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org; gen-...@ietf.org Review Team Cc: The IETF Subject: Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-ikev2-psk-diameter-07 Reviewer: Ben Campbell Review Date: 2011-06-03 IETF LC End Date: 2011-06-03 Summary: This draft is almost ready for publication as a proposed standard. I have a question concerning the procedure for generating PSKs, and a number of minor and editorial comments. Major issues: The draft says that the procedure that the HAAA follows to generate the PSK is out of scope. But doesn't the IKE2 initiator need to understand the procedure? If the procedure is not defined somewhere, how you achieve any degree of interoperability? [VC] Indeed the IKEv2 initiator needs to understand the procedure. However, this draft focuses on IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre-shared key based authentication, and specifies Diameter application for this communication. It is left to specifications that make use of this Diameter application to specify where the PSK comes from and how it is generated. There are two 3GPP2 specs that make use of this Diameter application and both of those specs specify generation of the PSK. Statements to clarify this are added in v8. The effect of this is that this spec, as written, cannot be implemented in an interoperable way. I don't think that meets the usual expectations for a proposed standard. Now, I realize there are some situations where the IETF has chosen this approach, and deliberately created a standards track RFC that must be profiled for actual use--but hopefully that's the exception rather than the rule. I guess it's up to the IESG to decide if that is reasonable in this instance. (I'm explicitly not counting situations where the IETF puts out a standard as a series of modular RFCs, since I gather there's no immediate intent to publish PSK generation RFCs.) Additionally, whether or not PSK generation mechanisms are specified in the IETF vs somewhere else, how does an implementation (that might support more than one such mechanism) know which to use for any given SA? Is there a negotiation mechanism? Minor issues: [...] -- section 10: The security considerations should describe the threat models. We're talking about requesting an authentication key from a third party, which is tricky from a security perspective. Does the PSK have greater security concerns than for Diameter AVPs in general? In particular, what are the consequences if the PSK is disclosed or tampered with? [VC] If the PSK is disclosed to an adversary then it would present a security breach. Hence we recommend that the PSK be short-lived. As well, the assumption is that the IKEv2 Server and the Diameter Server where the PSK is generated are in a trusted relationship. They may be in the same Administrative domain (typical case) or third party but nevertheless there is a trust relationship between them. As such we assume that there is an appropriate security mechanism to protect the communication between these servers. For example the IKEV2 Server and the Diameter server would be deployed in the same secure network or would utilize transport layer security as specified by Diameter 3588 specification. We added statements in v8 to reflect this. Thanks, that probably helps (pending seeing the actual text). -- section 10, 1st paragraph: Furthermore, any agents that process IKEv2-PSK-Answer messages can see the contents of the Key AVP. For this reason, this specification strongly recommends avoiding Diameter agents when they cannot be trusted to keep the keys secret. Should that be normative? Is there no way to protect the PSK AVP from diameter agents? E.g. can it be encrypted? [VC] It is hard to use normative text here as this application can be used for many uses cases. Depending on the use case it may be possible to encrypt the PSK, however it is not possible to make it a requirement. I don't see why a SHOULD or RECOMMENDED would cause problems here, along with some short explanation of why it might not always be possible. Otherwise, the text says strongly recommends, when, without normative text, such
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: I don't know if it is intentional, however if I use Google's public 8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4 (via /etc/gai.conf under Linux/glibc), it seems that the video content of all youtube videos is now being delivered over IPv6. Yes, YouTube videos are currently being served on dual-stack hostnames. The percentage of YouTube users that uses 6to4 is less than 0.02%. The percentage of YouTube users that uses native IPv6 is approximately 0.2% - over 10x more. That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? I'm having and have been having 100% success rate (or near enough to it that I can remember) using 6to4 for a number of years, including with an IPv6 MTU of as large as my PPPoE connection will support i.e. my 6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos are coming over IPv6, I've paid a bit more attention to the quality of experience I've had, and have not found any reasons to change my preference back to native IPv4 instead of 6to4. Sure - you're one of the 80% for whom it works. But that wasn't my question - my question was what is the advantage? You said that you have near enough 100% success rate, but I bet that your IPv4 success rate is near enough 100% as well. So what are you gaining by using 6to4 to talk to YouTube? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.comwrote: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network ... about 80% of the time. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, and that case 2 is today solved more reliably, and in more cases (e.g., when no public IPv4 address is available at the border) by the various NAT traversal mechanisms that are implemented in applications. But I think we're just going around in circles here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews ma...@isc.org wrote: ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. No, because you often end up being dependent on the whims of BGP and third-party relays for your return path. Sure, if you have enough control over routing in a closed network, you can make sure the right relays are used. But in that case, why not use configured tunnels? 6to4 historic is throwing the baby out with the bath water. On this we know we disagree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, 15 Jun 2011 18:43:23 -0700 Lorenzo Colitti lore...@google.com wrote: On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews ma...@isc.org wrote: ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. No, because you often end up being dependent on the whims of BGP and third-party relays for your return path. If you generalise that statement a bit, No, because you often end up being dependent on the whims of BGP and third-party routers for your return path. you're describing the trust inherent in the operation of the Internet, both for IPv4 and IPv6. Yes there are some incompetent operators out there, but most of them aren't - they wouldn't keep their jobs otherwise, and the Internet would break more often than it does. I can only remember one instance of 6to4 relay breakage in the last 5 years, and IIRC that was fixed within 24 hours. People seem to be using a very coarse less than absolute 100% success means total technology failure to state that 6to4 as a whole is unreliable. Where is the data to back this up? Did Geoff Huston do any more detailed analysis of the 6to4 data, other than measuring success verses failure rates for 6to4 connections? Could I, for example, have warped his 6to4 failure rates during the test if I used all my 2^16 x 2^64 IPv6 6to4 addresses to purposely create excessive failed 6to4 connections apparently from many different hosts? I'm certainly not saying that exists in Geoff's data, rather asking how do we know that it doesn't? I have a vested interest in anycast 6to4 continuing to exist, because it has been as reliable as any other Internet technology I use. I also think it has some latency advantages over configured tunnels because my IPv6 traffic enters the IPv6 Internet where ever the closest 6to4 relay reachable via IPv4 is. That used to be in Europe (around 14000 Km from me) when I first started using 6to4, now it is only around 3000 Km, and as my ISP is going to deploy a 6to4 relay in the near future, will be around 8Km away. These changes have and will continue to be transparent on my end. I'd also get these latency benefits if I was changing my IPv4 Internet points of attachment, such as if I were travelling internationally. Anycast 6to4 also tends to distribute the IPv6 traffic load better across all the 6to4 globally gateways, instead of concentrating it at likely lower number of configured tunnel entry/exit points. Over time, increased IPv6 traffic will become a disincentive to running a configured tunnel entry/exit point because people will continue to use it even if there is a more local configured tunnel or 6to4 relay they could be using. If people use anycast 6to4, then they inherently get lower latency as a closer one becomes available, and 6to4 relay operators will see lower traffic load without intervention as more 6to4 relays are deployed. Sure, if you have enough control over routing in a closed network, you can make sure the right relays are used. But in that case, why not use configured tunnels? 6to4 historic is throwing the baby out with the bath water. On this we know we disagree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote: I have a vested interest in anycast 6to4 continuing to exist, This actually brings up a good argument: are you going to pay for us to run our 6to4 relay? not that the cost of it is high, but there is cost to it - to make sure it keeps working, to monitor the system for overload, etc. Our customers don't really need it (because we have native IPv6), we're offering this for free to benefit users on the other side that do not have native IPv6, but insist on not using IPv4. And this also points out why anycasted 6to4 is necessarily(!) less reliable than those other Internet technologies that you have mentioned - because those that run the relays usually have no financial interest in doing so. So if it breaks, it will take longer to notice and even longer to fix than for something that directly affects paying customers. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi Gert, On Thu, 16 Jun 2011 08:51:26 +0200 Gert Doering g...@space.net wrote: Hi, On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote: I have a vested interest in anycast 6to4 continuing to exist, This actually brings up a good argument: are you going to pay for us to run our 6to4 relay? not that the cost of it is high, but there is cost to it - to make sure it keeps working, to monitor the system for overload, etc. It was a conscious decision of yours to announce it globally, so you've made a conscious decision to provide it to people for free and to take on the operational responsibilities of doing so. If you become unhappy with accepting those costs without corresponding compensation, withdraw the 6to4 anycast IPv4 address from the global route table, and people like me would move onto another 6to4 relay automatically. I certainly don't take for granted people's generosity in providing them to global users, however I think that if you choose to do something charitable, you have then created an obligation on yourself to do it well and reliably. Most people both understand and deliver on that obligation. I've actually become more conscious of this lack of financial incentive since I've noticed that youtube videos are coming to me over IPv6. That's what prompted me to ask if my ISP was planning to deploy a 6to4 relay soon as an interim step towards their native service. Our customers don't really need it (because we have native IPv6), we're offering this for free to benefit users on the other side that do not have native IPv6, but insist on not using IPv4. And this also points out why anycasted 6to4 is necessarily(!) less reliable than those other Internet technologies that you have mentioned - because those that run the relays usually have no financial interest in doing so. So if it breaks, it will take longer to notice and even longer to fix than for something that directly affects paying customers. Actually, a broken local 6to4 relay is likely to be impacting your paying customers too as it is their local 6to4 relay. Your arguments are not specific to 6to4 though - I think they apply to anybody providing a free configured tunnel service too. In some cases they apply more so - the administrative effort to support automated provisioning of configured tunnels is greater than that involved in setting up an anycast 6to4 relay. Regards, Mark. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [apps-discuss] Last Call: draft-ietf-appsawg-rfc3536bis-02.txt (Terminology Used in Internationalization in the IETF) to BCP
Hello all, I have an only concern with regard to this document which I expressed before, during WG discussions, and which I'd like to bring to IESG's attention now. For a number of times I proposed improving the control character definition in Section 4.1: control character The 65 characters in the ranges U+..U+001F and U+007F..U+009F. The basic space character, U+0020, is often considered as a control character as well, making the total number 66. They are also known as control codes. In terminology adopted by Unicode from ASCII and the ISO 8859 standards, these codes are treated as belonging to three ranges: C0 (for U+..U+001F), C1 (for U+0080...U+009F), and the single control character DEL (U+007F). UNICODE My proposals included http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02558.html and http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02589.html. The main justification I provided is that, in accordance with Abstract: This document provides a glossary of terms [...] so we need to specify what does the control character mean but not what Unicode codepoints are assigned for control characters. Yet, on the apps-discuss mailing list there were some concerns regarding the fact that control characters are unfamiliar to internalization so my proposed definition is not an option (one of the authors shares this opinion). Thus, why does it occur in its current form? So, there are two possible variants, I think: (1) remove the control character definition from the document as irrelevant to internalization or (2) produce a really good definition of this term (consider we're trying to give the terms normative meaning within IETF, since the intended status is BCP). I didn't manage to persuade the authors or WG to undertake any of the aforementioned options and I hope IESG should decide on this. Also, as a minor remark on references. The document makes normative reference to an obsolete document - ISO/IEC 10646:2003 whereas ISO/IEC 10646:2011 is published. The reference should be corrected. Thanks, Mykyta Yevstifeyev 16.06.2011 16:04, The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Terminology Used in Internationalization in the IETF' draft-ietf-appsawg-rfc3536bis-02.txt as a BCP 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 2011-06-30. 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 document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ No IPR declarations have been submitted directly on this I-D. ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
16.06.2011 12:35, Julian Reschke wrote: On 2011-06-16 11:20, Lachlan Hunt wrote: On 2011-06-16 11:14, Julian Reschke wrote: On the other hand, you're trying to define a URI scheme. If it's handling conflicts with the base URI spec, that's a bug. Period. You may *document* that some UAs have this bug, but you can't change it to be not a bug. Theoretical purity is not a priority for the specs I edit. Wilful violations of other specs where necessary are acceptable. Lachlan, with all due respect, I really do not care what *your* priorities here are. If you define a URI scheme, you'll have to be consistent with URI syntax. There's really no wiggle room except for warning about implementations that may not do it right. Please note that we're trying to produce the specification of the scheme which is used internally by the browsers. Thus, it is almost impossible to consider all existing behavior of all existing browsers. In order to avoid such situation as we currently have with Gecko, when an application is known to fail to satisfy one of the regulations of the Standards Track document, I think we could make the document Informational, which will specify the most common practice while mentioning some other non-common behavior. In this way we will fail to standardize the scheme, but at least won't create a lot of conflicts, which, IMO, is more important. As for the normalization of the about URIs. They are a subject to RFC 3986, being URIs, and are a subject to its normalization rules. Making an exception for them isn't an option, I think. Mykyta Yevstifeyev Best regards, Julian ___ 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: [apps-discuss] Last Call: draft-ietf-appsawg-rfc3536bis-02.txt (Terminology Used in Internationalization in the IETF) to BCP
On Thu, Jun 16, 2011 at 11:21 PM, Mykyta Yevstifeyev evniki...@gmail.com wrote: I have an only concern with regard to this document which I expressed before, during WG discussions, and which I'd like to bring to IESG's attention now. For a number of times I proposed improving the control character definition in Section 4.1: And in the WG discussions, Mykyta was in the rough when it came to a consensus judgment. I, as chair and doc shepherd, actually supported some change initially, but was convinced that the final text that's in the document is best. The document isn't meant to be a history lesson, but to make it clear what certain terms refer to. The current control character text accomplishes that, and there's been no support for Mykyta's suggested change. Barry, appsawg chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
15.06.2011 23:16, Andrew Sullivan wrote: On Wed, Jun 15, 2011 at 06:05:33PM +0300, Mykyta Yevstifeyev wrote: 15.06.2011 13:13, Julian Reschke wrote: That being said, if our Mozilla friends do not want to fix this it might be a good idea to warn readers that certain implementations fail to properly unescape, thus it's unwise to rely on that behavior (why would you anyway?). I fully agree with you, Julian. I think we'll do certainly as you propose, unless Boris will provide some strong reasons to do in other way. If I am reading the document and the above correctly, then you are proposing the following: 1. The document proposes to make standard rules about what applications do with input that is, by definition, completely internal to that application; and, 2. You propose in addition to state what is the standard, but note that nobody should rely on it because one of the largest implementers of the scheme doesn't follow the supposed standard. Currently and actually I have nearly the same concern. The -02 version still had Informational intended status, I don't know what was a reason for switching to Standards Track. I have a feeling that producing the Informational RFC describing the most common behavior is an option, but we'll fail to standardize the scheme. I personally think standardizing the internal-usage scheme is a bit irrelevant, so here i agree with you. Do I have this correct? If so, I would like to request that the WINDMILL or perhaps TILT WG be chartered to deal with this manner of work. More substantively, I fail to understand how this specification proposes to create a class of reserved about: URIs when the about: scheme seems to be internal information to an application. I think the Security Considerations section doesn't address any of that, and probably ought to, particularly in light of the proposal to add text that users ought not to depend on standard behaviour. That's an interesting point as well. Trying to standardize the abut URI scheme, we're trying to state that URI about: is used only and only fir the purpose whereas about: is used only for purpose . I understand your concern regarding different purposes of one about URI in different apps. I can share it with you as well. As a result, abandoning the intends to give the scheme a Standards Track specification and complete revision of regulations with regard to resolving about URIs may be an option. Mykyta Yevstifeyev Best, A ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
More substantively, I fail to understand how this specification proposes to create a class of reserved about: URIs when the about: scheme seems to be internal information to an application. I think the Security Considerations section doesn't address any of that, and probably ought to, particularly in light of the proposal to add text that users ought not to depend on standard behaviour. Yes... I'm actually very confused about the point of this document. It's documenting a URI scheme that's used ONLY internally, and, therefore, has no interoperability requirements. As best I can tell, the issue here is to let browser makers know what other browsers do, so that maybe new browsers will decide to do the same things. That's fine, and that helps users have a consistent experience across browsers. But it strikes me as Informational, not Standards Track. MUSTs and MUST NOTs seem completely out of place here, to me. If different browsers exhibit different behaviour with the same about: URI, that's as it is, and the variations should be documented. Developers of new browsers will have to decide which older browsers to emulate. But none of this actually speaks to interoperability among browsers or web servers or applications or Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
16.06.2011 11:59, Lachlan Hunt wrote: On 2011-06-15 17:59, Boris Zbarsky wrote: On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote: The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. No, it's to propose abandoning normalization because it's not necessarily compatible with existing deployed uses of about:, Probably. Because of this in my previous messages I proposed abandoning making the spec. Standards Track. not clearly compatible with the web security model, How? and because the normalization is not defined in the spec. Normalization is defined in RFC 3986. The Gecko behavior is just an illustration of the first point. The purpose of our draft is to give a stable specification of the scheme Yes, this is fine. But see above. and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. Mykyta, we do need to make this spec document reality, particularly where implementations are unwilling to make changes. I agree; but different existing behavior makes this impossible. We can't list everything which is currently supported by all implementations in the Standards Track document, but we can do this in the Informational. Mykyta If it doesn't do that, then the spec is useless. I will be reviewing the options and look into exactly how other browsers handle these cases, and make appropriate changes to the spec. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Barry Leiba Sent: Thursday, June 16, 2011 9:01 PM To: Andrew Sullivan Cc: draft-holsten-about-uri-sch...@tools.ietf.org; IETF Discussion; Julian Reschke; Boris Zbarsky; Alexey Melnikov Subject: Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard Yes... I'm actually very confused about the point of this document. It's documenting a URI scheme that's used ONLY internally, and, therefore, has no interoperability requirements. As best I can tell, the issue here is to let browser makers know what other browsers do, so that maybe new browsers will decide to do the same things. That's fine, and that helps users have a consistent experience across browsers. But it strikes me as Informational, not Standards Track. MUSTs and MUST NOTs seem completely out of place here, to me. If different browsers exhibit different behaviour with the same about: URI, that's as it is, and the variations should be documented. Developers of new browsers will have to decide which older browsers to emulate. But none of this actually speaks to interoperability among browsers or web servers or applications or I suppose adding it as an IANA-registered scheme, referencing something that's Informational, is a reasonable way for a new browser implementer to be reminded that support for such a scheme is common and probably expected. But if we feel that's either not useful or not the IETF's place (or not a valid use of the IANA scheme registry), then I'm left to +1 Barry's comments above. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 146 messages in the last 7 days. script run at: Fri Jun 17 00:53:01 EDT 2011 Messages | Bytes| Who +--++--+ 9.59% | 14 | 9.56% | 100323 | mo...@network-heretics.com 8.22% | 12 | 10.90% | 114417 | lore...@google.com 5.48% |8 | 5.39% |56570 | evniki...@gmail.com 4.11% |6 | 3.85% |40372 | ma...@isc.org 4.11% |6 | 3.84% |40273 | joe...@bogus.com 3.42% |5 | 3.62% |38023 | brian.e.carpen...@gmail.com 4.11% |6 | 2.73% |28627 | mic...@arneill-py.sacramento.ca.us 3.42% |5 | 2.64% |27665 | j...@apple.com 2.74% |4 | 2.87% |30154 | john-i...@jck.com 2.74% |4 | 2.63% |27580 | i...@69706e6720323030352d30312d31340a.nosense.org 2.05% |3 | 3.18% |33360 | alh-i...@tndh.net 1.37% |2 | 3.61% |37906 | otuene...@gmail.com 2.74% |4 | 1.98% |20799 | julian.resc...@gmx.de 2.74% |4 | 1.84% |19305 | j...@mercury.lcs.mit.edu 1.37% |2 | 3.07% |32216 | yaronf.i...@gmail.com 2.74% |4 | 1.63% |17101 | jo...@iecc.com 2.05% |3 | 2.13% |22347 | daedu...@btconnect.com 1.37% |2 | 2.50% |26237 | violeta.caku...@alcatel-lucent.com 2.05% |3 | 1.57% |16517 | m...@sandelman.ca 2.05% |3 | 1.32% |13905 | mo...@necom830.hpcl.titech.ac.jp 1.37% |2 | 1.96% |20577 | stefan.win...@restena.lu 1.37% |2 | 1.45% |15222 | cb.li...@gmail.com 1.37% |2 | 1.34% |14050 | n...@guppylake.com 1.37% |2 | 1.29% |13553 | m...@sabahattin-gucukoglu.com 1.37% |2 | 1.08% |11307 | lachlan.h...@lachy.id.au 1.37% |2 | 0.98% |10291 | jari.ar...@piuha.net 0.68% |1 | 0.94% | 9838 | b...@nostrum.com 0.68% |1 | 0.86% | 9011 | a...@bridgewatersystems.com 0.68% |1 | 0.83% | 8666 | elw...@dial.pipex.com 0.68% |1 | 0.78% | 8181 | hsan...@isdg.net 0.68% |1 | 0.77% | 8029 | nar...@us.ibm.com 0.68% |1 | 0.75% | 7880 | hamza.gharsal...@gmail.com 0.68% |1 | 0.74% | 7766 | fred.l.temp...@boeing.com 0.68% |1 | 0.74% | 7745 | tom111.tay...@bell.net 0.68% |1 | 0.72% | 7539 | berti...@bwijnen.net 0.68% |1 | 0.72% | 7525 | suresh.krish...@ericsson.com 0.68% |1 | 0.71% | 7503 | j...@wide.ad.jp 0.68% |1 | 0.70% | 7360 | trej...@gmail.com 0.68% |1 | 0.67% | 7062 | rdroms.i...@gmail.com 0.68% |1 | 0.66% | 6906 | bzbar...@mit.edu 0.68% |1 | 0.62% | 6476 | to...@isi.edu 0.68% |1 | 0.61% | 6366 | ned+i...@mauve.mrochek.com 0.68% |1 | 0.60% | 6249 | tnad...@lucidvision.com 0.68% |1 | 0.58% | 6129 | d...@cridland.net 0.68% |1 | 0.58% | 6119 | otr...@employees.org 0.68% |1 | 0.56% | 5906 | e...@google.com 0.68% |1 | 0.56% | 5879 | g...@space.net 0.68% |1 | 0.55% | 5766 | j...@joelhalpern.com 0.68% |1 | 0.55% | 5728 | co...@isoc.org 0.68% |1 | 0.54% | 5700 | t...@ecs.soton.ac.uk 0.68% |1 | 0.52% | 5451 | a...@anvilwalrusden.com 0.68% |1 | 0.51% | 5395 | rog...@gmail.com 0.68% |1 | 0.51% | 5372 | barryle...@computer.org 0.68% |1 | 0.50% | 5252 | huit...@microsoft.com 0.68% |1 | 0.47% | 4918 | dwor...@avaya.com 0.68% |1 | 0.46% | 4840 | s...@cs.columbia.edu 0.68% |1 | 0.44% | 4604 | do...@dougbarton.us 0.68% |1 | 0.44% | 4603 | i...@ietf.org 0.68% |1 | 0.43% | 4528 | c...@a.org 0.68% |1 | 0.42% | 4447 | krishnabi...@gmail.com +--++--+ 100.00% | 146 |100.00% | 1049436 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-gellens-mime-bucket-bis-05.txt (The Codecs and Profiles Parameters for Bucket Media Types) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'The Codecs and Profiles Parameters for Bucket Media Types' draft-gellens-mime-bucket-bis-05.txt 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 i...@ietf.org mailing lists by 2011-07-14. 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 Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered. This document specifies two parameters, codecs and profiles, which are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs and/or profiles employed by the media formats contained within. This document obsoletes RFC 4281; RFC 4281 defines the codecs parameter, which this document retains in a backwards compatible manner with minor clarifications; the profiles parameter is added by this document. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. The file can be obtained via http://datatracker.ietf.org/doc/draft-gellens-mime-bucket-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-gellens-mime-bucket-bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-appsawg-rfc3536bis-02.txt (Terminology Used in Internationalization in the IETF) to BCP
The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Terminology Used in Internationalization in the IETF' draft-ietf-appsawg-rfc3536bis-02.txt as a BCP 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 i...@ietf.org mailing lists by 2011-06-30. 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 document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ftpext2-hosts-02.txt (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
The IESG has received a request from the FTP Extensions, 2nd edition WG (ftpext2) to consider the following document: - 'File Transfer Protocol HOST Command for Virtual Hosts' draft-ietf-ftpext2-hosts-02.txt 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 i...@ietf.org mailing lists by 2011-06-30. 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 The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-karp-design-guide-02.txt (Keying and Authentication for Routing Protocols (KARP) Design Guidelines) to Informational RFC
The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'Keying and Authentication for Routing Protocols (KARP) Design Guidelines' draft-ietf-karp-design-guide-02.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2011-06-30. 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 In the March of 2006 the IAB held a workshop on the topic of Unwanted Internet Traffic. The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for [t]ightening the security of the core routing infrastructure. Four main steps were identified for improving the security of the routing infrastructure. One of those steps was securing the routing protocols' packets on the wire. One mechanism for securing routing protocol packets on the wire is the use of per-packet cryptographic message authentication, providing both peer authentication and message integrity. Many different routing protocols exist and they employ a range of different transport subsystems. Therefore there must necessarily be various methods defined for applying cryptographic authentication to these varying protocols. Many routing protocols already have some method for accomplishing cryptographic message authentication. However, in many cases the existing methods are dated, vulnerable to attack, and/or employ cryptographic algorithms that have been deprecated. This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. The overall roadmap reflects the input of both the security area and routing area in order to form a jointly agreed upon and prioritized work list for the effort. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sidr-rescerts-provisioning-10.txt (A Protocol for Provisioning Resource Certificates) to Proposed Standard
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'A Protocol for Provisioning Resource Certificates' draft-ietf-sidr-rescerts-provisioning-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-30. 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 document defines a framework for certificate management interactions between a resource issuer (Issuer) and a resource recipient (Subject) through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the Subject, and corresponding responses from the Issuer encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rescerts-provisioning/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rescerts-provisioning/ No IPR declarations have been submitted directly on this I-D. Two downrefs occur in this document: RFC2986 and RFC5781. RFC5781 is already registered in the downref registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-codec-requirements-04.txt (Codec Requirements) to Informational RFC
The IESG has received a request from the Internet Wideband Audio Codec WG (codec) to consider the following document: - 'Codec Requirements' draft-ietf-codec-requirements-04.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2011-06-30. 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 document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet loss robustness, as well as other desirable properties. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
