Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
--On Sunday, January 01, 2012 19:55 +0100 Bjoern Hoehrmann derhoe...@gmx.net wrote: Among the goals of the Internet Standards Process are openness and fairness and I would find these principles grossly violated if the IESG would approve the document for publication with the proposed changes applied but without another Last Call. With another Last Call and if there is rough consensus in favour of the changes, and that'd include running code, then that's fine with me, regardless of whether an intention to publish an Internet-Draft as RFC is communicated to some obscure W3C mailing list, or who communicates such an intention. Björn, For better or worse, the IETF tries to maintain close working relationships with a number of other SDOs. While there are exceptions, those relationships work best when we are willing to go out of our way to be sure that everyone stays informed and, in particular, that we don't appropriate their standards or conventions and start making changes to them... and when they reciprocate. While different ADs handle it differently, we have also traditionally made the assumption that authors requesting individual submission publication have to take most of the responsibility for making sure all of the ducks are lined up. They cannot, for example, rely on a WG to do that (since there isn't one) nor on IETF Last Call to spot everything that they, who are presumably expert enough to have constructed the document in the first place, should have spotted. That said, I basically agree with what you have written above, tempered by the understanding that I think it is in the IETF's best interest (as well as just plain polite) to go to W3C and say, repeatedly if necessary, do you really, really, not have anything to say about this? We certainly expect the same from other SDOs we work with and W3C has give us that courtesy on some occasions when we have been slow to respond. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
hat type='AD'/ On 1/2/12 12:36 AM, Mykyta Yevstifeyev wrote: While that was me who proposed the change to semantics, I tend more and more to agree with documenting the existing practice; but let's wait a response from W3C community first to see what's their attitude towards the proposal. Mykyta, You have not yet submitted a revised I-D. Currently the document under consideration is draft-yevstifeyev-disclosure-relation-00. If you want to make fundamental changes to the spec, please do so by submitting a revised I-D. In the meantime, I have deferred the document to the January 19 telechat while you decide how you want to proceed. If you decide that you want to define two link relations instead of one, you will need to submit a revised I-D, which will need to undergo another review on the link-relati...@ietf.org list and then another IETF Last Call. There is no need to waste IESG and general IETF attention on this specification if the author can't make up his mind about his own intentions. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
--On Monday, January 02, 2012 09:36 +0200 Mykyta Yevstifeyev evniki...@gmail.com wrote: ... I believe that the IESG ought to take exceptional care with individual submissions, precisely because they are published in the IETF stream, requiring significant expertise or careful reading to determine whether they actually represent informed and competent IETF consensus. Against that test, this document is not ready for approval and RFC publication. Specific examples: (1) The second sentence of the Introduction begins This document specifies a new type of such relationship But this is not new: it has been around for years, as the next paragraph (and comments on the IETF list) indicate. It's new in context of being formally registered. Then say that it specifies a registration for something that has been around for a while, not that it is new. (2) The last paragraph of the Introduction reads: This document is to formally register the 'disclosure' Link Relation Type with IANA and provide a permanent record on it for the Internet community. Additionally, it expands the sphere of this relation type to allow its use when referring to separate patent disclosures. So it registers the type (good, IMO); makes a permanent and public record --which the author believes W3C has failed to do (good, IMO); documents the existing practice (also good, IMO); and creates an untested extension (outside the scope of Informational publication of an existing practice, IMO). So do you propose dropping the semantics for separate disclosures and leaving the original W3C's? I propose that you figure out what you want to do, that you be very explicit about what (if anything) is new and what is existing practice, and that you get out a new I-D that says whatever you intend. If you are asking me the substantive question, I think that, if you are going to propose an extension, you are obligated to be very clear what the extension is and to do a careful review of what issues might arise with it. I'm not sure I have an opinion about whether the extension is a good idea -- I need that information to figure it out and I think it is your obligation to supply it. I think what I'm saying here is consistent in general principles, if not in detail, with Peter's recent note -- making what you are proposing clear is your responsibility. Please don't ask the community to spend time on review until you have a very specific and clear proposal with which you are satisfied. ... (4) While it is not unusual for Acknowledgments sections to be updated during or after Last Call, an entry of TBD for the only contributors to the document make it impossible for the community to verify that the BCP78 requirements have been followed. TBD occurred because there were no comments received before LC; but now, I hope, this may be corrected. Then get a new I-D posted (see Peter's note). I think this document could be cleaned up and made ready for publication by using any of the following three options: ... (iii) Modify this document to be _extremely_ clear about what is existing practice and what is the author's suggestion about an extension. For the latter, the change being made, the justification for it, and a risk analysis should be present and explicit. While that was me who proposed the change to semantics, I tend more and more to agree with documenting the existing practice; but let's wait a response from W3C community first to see what's their attitude towards the proposal. Documenting the existing spec would work for me (but so would doing so and adding a well-vetted and well-documented extension). I do suggest that you not wait for a response from W3C but that you try to actively engage with them, seeking help from Thomas, Julian, Mark, or others as appropriate. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Julian, all, When I came to fixing the examples section per received comments, I first began to refine the example on references to separate disclosures, and what I got was: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html (unchanged fragment of list) and, later, a rel=disclosure href=https://datatracker.ietf.org/ipr/1097/;IPR Disclosure #1097/a (this was fixed to suit real situation with RFC 5925). And, after a closer look, I realized that the separate-patent-disclosure semantics and a list-thereof one are completely different. That is a simple and compelling reason, I think, to distinguish the semantics. And that's why we have 'item' and 'collection' relations (now in LC) defined as pair (actually, what my document defines may be considered to be a special case of these in some way). The only thing is that such proposed definition is different from the current W3C's use of 'disclosure' relation, which is used as my proposed 'disclosure-list', but once we have defined both, W3C will migrate to a new, correct one (I hope). All the best, and happy New Year, Mykyta Yevstifeyev 2011/12/29 Julian Reschke julian.resc...@gmx.de: On 2011-12-27 07:52, Mykyta Yevstifeyev wrote: Hello, I'd like to seek consensus on separating the semantics of link relation for separate disclosure and a list thereof, correspondingly defining two link relations - 'disclosure' and 'disclosure-list'. You may see my edits made to Section 2 of the doc. below, which I'm proposing: 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI [RFC5988] MUST refer to a particular patent disclosure made with respect to the material being referenced by context IRI. 3. 'disclosure-list' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST designate a list of patent disclosures made with respect to the material being referenced by context IRI. As the doc. is in Last Call now, in order not to initiate a new one, please comment on these changes before January 6, so that I could know which version I should submit for IESG evaluation. ... I don't see a compelling reason to distinguish both. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2012-01-01 09:25, Mykyta Yevstifeyev wrote: Julian, all, When I came to fixing the examples section per received comments, I first began to refine the example on references to separate disclosures, and what I got was: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html (unchanged fragment of list) and, later, a rel=disclosure href=https://datatracker.ietf.org/ipr/1097/;IPR Disclosure #1097/a (this was fixed to suit real situation with RFC 5925). And, after a closer look, I realized that the separate-patent-disclosure semantics and a list-thereof one are completely different. That is a simple and compelling reason, I think, to distinguish the semantics. And that's why we have 'item' and 'collection' relations (now in LC) defined as pair (actually, what my document defines may be considered to be a special case of these in some way). The only thing is that such proposed definition is different from the current W3C's use of 'disclosure' relation, which is used as my proposed 'disclosure-list', but once we have defined both, W3C will migrate to a new, correct one (I hope). All the best, and happy New Year, Mykyta Yevstifeyev ... Not convinced. I thought the purpose was to document an existing use? Now you're adding another one (post-LC), and it's (as far as I can tell) totally unclear what the W3C's take on this is. (they introduced the link relation, after all) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Julian, I'd be glad to describe current use, but as long as we want to introduce a possibility to reference separate disclosures, we cannot fit two separate semantic models in one relation type. And the naming 'disclosure' suits separate instances of disclosures rather than a list. And, should there be no objections, the document may be processed with the change without 2nd LC. Mykyta Yevstifeyev 2012/1/1 Julian Reschke julian.resc...@gmx.de: On 2012-01-01 09:25, Mykyta Yevstifeyev wrote: Julian, all, When I came to fixing the examples section per received comments, I first began to refine the example on references to separate disclosures, and what I got was: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html (unchanged fragment of list) and, later, a rel=disclosure href=https://datatracker.ietf.org/ipr/1097/;IPR Disclosure #1097/a (this was fixed to suit real situation with RFC 5925). And, after a closer look, I realized that the separate-patent-disclosure semantics and a list-thereof one are completely different. That is a simple and compelling reason, I think, to distinguish the semantics. And that's why we have 'item' and 'collection' relations (now in LC) defined as pair (actually, what my document defines may be considered to be a special case of these in some way). The only thing is that such proposed definition is different from the current W3C's use of 'disclosure' relation, which is used as my proposed 'disclosure-list', but once we have defined both, W3C will migrate to a new, correct one (I hope). All the best, and happy New Year, Mykyta Yevstifeyev ... Not convinced. I thought the purpose was to document an existing use? Now you're adding another one (post-LC), and it's (as far as I can tell) totally unclear what the W3C's take on this is. (they introduced the link relation, after all) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Mykyta, thank you for working on this draft. Before you try to get a specification through Last Call that's possibly at odds with the current (and as far as I know original) use of the link relationship, it would perhaps be useful to talk to the current users of this particular link relationship, and request their review of the specification, and find out their views on the proposed change to its semantics. A good place to reach many of the interested parties would be the spec-p...@w3.org mailing list. Also, I'd recommend that you contact Ian Jacobs, W3C's head of communications; he's in charge of the detailed publication requirements for W3C specifications. Before these steps have happened, it would appear premature to me to request publication of this document as an RFC. Regards, -- Thomas Roessler, W3C t...@w3.org (@roessler) On 2012-01-01, at 15:04 +0100, Mykyta Yevstifeyev wrote: Julian, I'd be glad to describe current use, but as long as we want to introduce a possibility to reference separate disclosures, we cannot fit two separate semantic models in one relation type. And the naming 'disclosure' suits separate instances of disclosures rather than a list. And, should there be no objections, the document may be processed with the change without 2nd LC. Mykyta Yevstifeyev 2012/1/1 Julian Reschke julian.resc...@gmx.de: On 2012-01-01 09:25, Mykyta Yevstifeyev wrote: Julian, all, When I came to fixing the examples section per received comments, I first began to refine the example on references to separate disclosures, and what I got was: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html (unchanged fragment of list) and, later, a rel=disclosure href=https://datatracker.ietf.org/ipr/1097/;IPR Disclosure #1097/a (this was fixed to suit real situation with RFC 5925). And, after a closer look, I realized that the separate-patent-disclosure semantics and a list-thereof one are completely different. That is a simple and compelling reason, I think, to distinguish the semantics. And that's why we have 'item' and 'collection' relations (now in LC) defined as pair (actually, what my document defines may be considered to be a special case of these in some way). The only thing is that such proposed definition is different from the current W3C's use of 'disclosure' relation, which is used as my proposed 'disclosure-list', but once we have defined both, W3C will migrate to a new, correct one (I hope). All the best, and happy New Year, Mykyta Yevstifeyev ... Not convinced. I thought the purpose was to document an existing use? Now you're adding another one (post-LC), and it's (as far as I can tell) totally unclear what the W3C's take on this is. (they introduced the link relation, after all) 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: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
* Thomas Roessler wrote: thank you for working on this draft. Before you try to get a specification through Last Call that's possibly at odds with the current (and as far as I know original) use of the link relationship, it would perhaps be useful to talk to the current users of this particular link relationship, and request their review of the specification, and find out their views on the proposed change to its semantics. A good place to reach many of the interested parties would be the spec-p...@w3.org mailing list. Also, I'd recommend that you contact Ian Jacobs, W3C's head of communications; he's in charge of the detailed publication requirements for W3C specifications. Before these steps have happened, it would appear premature to me to request publication of this document as an RFC. If Ian Jacobs is responsible for the things discussed on spec-prod, I'd think he reads that mailing list, and the mailing list has been aware of the draft since the first version has been published in October 2011, http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0008.html. What might be useful is to ask W3C's IETF Liaison what W3C's policy is with respect to registration of link relations W3C makes up and uses on its web site. The Internet Community shouldn't really have to clean up after the W3C to ensure proper registration of link relations W3C uses. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: thank you for working on this draft. Before you try to get a specification through Last Call that's possibly at odds with the current (and as far as I know original) use of the link relationship, it would perhaps be useful to talk to the current users of this particular link relationship, and request their review of the specification, and find out their views on the proposed change to its semantics. A good place to reach many of the interested parties would be the spec-p...@w3.org mailing list. Also, I'd recommend that you contact Ian Jacobs, W3C's head of communications; he's in charge of the detailed publication requirements for W3C specifications. Before these steps have happened, it would appear premature to me to request publication of this document as an RFC. If Ian Jacobs is responsible for the things discussed on spec-prod, I'd think he reads that mailing list, and the mailing list has been aware of the draft since the first version has been published in October 2011, http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0008.html. Neither the intention to last call the draft, nor the proposed incompatible change were announced to that list. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
* Thomas Roessler wrote: On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: Before these steps have happened, it would appear premature to me to request publication of this document as an RFC. Neither the intention to last call the draft, nor the proposed incompatible change were announced to that list. So what is the point of order you are trying to raise? Registering the link relation pretty much requires publication of the draft as RFC, so the intent should be implicit, and given the length of the draft, and my review comments, the timing should be rather clear to anyone who cared aswell, so I don't see how the request for publication was prema- ture. If you only want to make sure interested parties are aware of the state of the discussion around the document, you can just tell them, like I did when I copied my review comments to spec-prod, or point this thread out to W3C's IETF Liaison so they can spread the word for you. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Bjoern, I'm not interested in a game of process nomics. rel=disclosure has been in actual and continuous use in highly stable documents for almost 10 years now; a very quick search turns up early usage in late 2002. As far as I can tell, it starts to show up as a suggestion in the W3C publication rules some time between April and September 2002. That predates the Web Linking spec (and its creation of the current relationship value registry) by about 8 years. The draft before the IETF now started out as inspired by and documenting the existing usage. That is a very welcome and useful thing to do. The proposal is now — in last call — changing into hey, let's actually redefine the usage of that link relationship, W3C will just follow. I think that that is an unwise step unless you actually have buy-in from those who build the current W3C tool-chain, and from those who maintain the current set of documents. The very least I'd expect is that those who propose the change make an effort to get in touch with the current users of the link relationship. Posting an idea to ietf@ietf.org is not a good way to do so. Further, I think that it will be pretty unlikely that we'll make changes to Recommendations and other publications going back over 10 years to accommodate the proposed new usage. Speaking personally, -1 to the proposed change of semantics. Speaking as liaison, I've already pointed you at the appropriate people to ask for review. This being an individual, informational draft, I think it's fair to expect the submitter to go and secure the appropriate review. Regards, -- Thomas Roessler, W3C t...@w3.org (@roessler) On 2012-01-01, at 17:13 +0100, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: Before these steps have happened, it would appear premature to me to request publication of this document as an RFC. Neither the intention to last call the draft, nor the proposed incompatible change were announced to that list. So what is the point of order you are trying to raise? Registering the link relation pretty much requires publication of the draft as RFC, so the intent should be implicit, and given the length of the draft, and my review comments, the timing should be rather clear to anyone who cared aswell, so I don't see how the request for publication was prema- ture. If you only want to make sure interested parties are aware of the state of the discussion around the document, you can just tell them, like I did when I copied my review comments to spec-prod, or point this thread out to W3C's IETF Liaison so they can spread the word for you. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
FWIW, I strongly support Thomas's position. This should either be a narrow description of existing practice or should not be approved by the IETF without review and buy-in from the communities who actually use and support this mechanism. john --On Sunday, January 01, 2012 18:06 +0100 Thomas Roessler t...@w3.org wrote: Bjoern, I'm not interested in a game of process nomics. rel=disclosure has been in actual and continuous use in highly stable documents for almost 10 years now; a very quick search turns up early usage in late 2002. As far as I can tell, it starts to show up as a suggestion in the W3C publication rules some time between April and September 2002. That predates the Web Linking spec (and its creation of the current relationship value registry) by about 8 years. The draft before the IETF now started out as inspired by and documenting the existing usage. That is a very welcome and useful thing to do. The proposal is now — in last call — changing into hey, let's actually redefine the usage of that link relationship, W3C will just follow. I think that that is an unwise step unless you actually have buy-in from those who build the current W3C tool-chain, and from those who maintain the current set of documents. The very least I'd expect is that those who propose the change make an effort to get in touch with the current users of the link relationship. Posting an idea to ietf@ietf.org is not a good way to do so. Further, I think that it will be pretty unlikely that we'll make changes to Recommendations and other publications going back over 10 years to accommodate the proposed new usage. Speaking personally, -1 to the proposed change of semantics. Speaking as liaison, I've already pointed you at the appropriate people to ask for review. This being an individual, informational draft, I think it's fair to expect the submitter to go and secure the appropriate review. Regards, -- Thomas Roessler, W3C t...@w3.org (@roessler) On 2012-01-01, at 17:13 +0100, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: Before these steps have happened, it would appear premature to me to request publication of this document as an RFC. Neither the intention to last call the draft, nor the proposed incompatible change were announced to that list. So what is the point of order you are trying to raise? Registering the link relation pretty much requires publication of the draft as RFC, so the intent should be implicit, and given the length of the draft, and my review comments, the timing should be rather clear to anyone who cared aswell, so I don't see how the request for publication was prema- ture. If you only want to make sure interested parties are aware of the state of the discussion around the document, you can just tell them, like I did when I copied my review comments to spec-prod, or point this thread out to W3C's IETF Liaison so they can spread the word for you. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ 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: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
* Thomas Roessler wrote: I'm not interested in a game of process nomics. If you are not interested in discussing whether it was premature ... to request publication of this document as an RFC then don't suggest that it was? The IETF is currently discussing proper procedures for this kind of third-party registration in various places like happiana, you will excuse that some of us are interested in finding suitable guidelines. Speaking as liaison, I've already pointed you at the appropriate people to ask for review. This being an individual, informational draft, I think it's fair to expect the submitter to go and secure the appropriate review. I think it's fair to expect you to keep people in the W3C apprised about developments in the IETF relevant to their work, and I think it's fair to dismiss your opinion in this matter given that you don't want to dis- cuss it. Mykyta Yevstifeyev made a draft, interested parties were made aware of the draft, and after some weeks with no comments from them, as far as I am aware, Mykyta Yevstifeyev asked for publication of the draft as RFC. I don't think there is anything wrong with that. If you disagree perhaps you can find someone to argue your point on the happiana list so we can give better guidance to our fellow community members. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2012-01-01 19:13, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: I'm not interested in a game of process nomics. If you are not interested in discussing whether it was premature ... to request publication of this document as an RFC then don't suggest that it was? The IETF is currently discussing proper procedures for this kind of third-party registration in various places like happiana, you will excuse that some of us are interested in finding suitable guidelines. Speaking as liaison, I've already pointed you at the appropriate people to ask for review. This being an individual, informational draft, I think it's fair to expect the submitter to go and secure the appropriate review. I think it's fair to expect you to keep people in the W3C apprised about developments in the IETF relevant to their work, and I think it's fair to dismiss your opinion in this matter given that you don't want to dis- cuss it. Mykyta Yevstifeyev made a draft, interested parties were made aware of the draft, and after some weeks with no comments from them, as far as I am aware, Mykyta Yevstifeyev asked for publication of the draft as RFC. I don't think there is anything wrong with that. If you disagree perhaps you can find someone to argue your point on the happiana list so we can give better guidance to our fellow community members. Björn, I'm almost with you. However, changing the actual definition and adding an additional post LC would be kind of surprising, wouldn't it? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
* Mykyta Yevstifeyev wrote: I'd like to seek consensus on separating the semantics of link relation for separate disclosure and a list thereof, correspondingly defining two link relations - 'disclosure' and 'disclosure-list'. You may see my edits made to Section 2 of the doc. below, which I'm proposing: 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI [RFC5988] MUST refer to a particular patent disclosure made with respect to the material being referenced by context IRI. 3. 'disclosure-list' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST designate a list of patent disclosures made with respect to the material being referenced by context IRI. As the doc. is in Last Call now, in order not to initiate a new one, please comment on these changes before January 6, so that I could know which version I should submit for IESG evaluation. I do not think you should (be able to) make such a change without a new Last Call, and I disagree with the separation. Reasons include that it's unclear which relation you use if you have one disclosure where many patents are disclosed; would that be disclosure because it's just one disclosure, or would it be a disclosure-list because many patents are disclosed? On the German Wikipedia people are even used to flamewars concerning List articles that have no or just one item, where some ar- gue that you need at least two items to have a list. In this sense you could probably always use 'disclosure-list' in place of 'disclosure' if you think empty and single item lists are meaningful concepts. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
* Julian Reschke wrote: I'm almost with you. However, changing the actual definition and adding an additional post LC would be kind of surprising, wouldn't it? Among the goals of the Internet Standards Process are openness and fairness and I would find these principles grossly violated if the IESG would approve the document for publication with the proposed changes applied but without another Last Call. With another Last Call and if there is rough consensus in favour of the changes, and that'd include running code, then that's fine with me, regardless of whether an intention to publish an Internet-Draft as RFC is communicated to some obscure W3C mailing list, or who communicates such an intention. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Hi. While I'm highly sympathetic to Thomas Roessler's position which I interpret as this needing (as a matter of courtesy and cooperation, if nothing else) affirmative signoff from the relevant parties in W3C, I would settle for any clear set of comments from them. But I think this also needs some examination in terms IETF relationships and process independent of the W3C-related issues. It is, IMO, entirely appropriate to publish a specification as Informational when it precisely describes some existing practice for the information of the community. We have a long history of doing that in what is now called the Independent and, when the specification bears some direct relationship to other IETF work, in the IETF stream. But this document, in the -00 version circulated for Last Call, is not such a precise, factual, description: it contains errors or misstatements (examples below) and it contains extensions beyond the existing practice that are not clearly identified and that, as far as I can tell, have not been deployed or tested.While I see no reason why they would not work, experience is the proper test of whether some particular approach or syntax is adequate. I believe that the IESG ought to take exceptional care with individual submissions, precisely because they are published in the IETF stream, requiring significant expertise or careful reading to determine whether they actually represent informed and competent IETF consensus. Against that test, this document is not ready for approval and RFC publication. Specific examples: (1) The second sentence of the Introduction begins This document specifies a new type of such relationship But this is not new: it has been around for years, as the next paragraph (and comments on the IETF list) indicate. (2) The last paragraph of the Introduction reads: This document is to formally register the 'disclosure' Link Relation Type with IANA and provide a permanent record on it for the Internet community. Additionally, it expands the sphere of this relation type to allow its use when referring to separate patent disclosures. So it registers the type (good, IMO); makes a permanent and public record --which the author believes W3C has failed to do (good, IMO); documents the existing practice (also good, IMO); and creates an untested extension (outside the scope of Informational publication of an existing practice, IMO). (3) There is no analysis at all of whether the compound use of this relation identifier (within a ul element) might confuse any existing implementations and, if so, how that confusion would play itself out. For example, we have learned the hard way in other areas that, when multiple instances of the same information-label appear with different values and without that being explicitly provided for in the specification, some implementations will use the first one and ignore the others, others will pick the last one and ignore the others, some will reject the construct entirely, and still others will try to somehow combine the fields. If we know what would happen here, the document doesn't say so. Without such an analysis, the statement of true belief in Security Considerations may be a little bit optimistic. (4) While it is not unusual for Acknowledgments sections to be updated during or after Last Call, an entry of TBD for the only contributors to the document make it impossible for the community to verify that the BCP78 requirements have been followed. I think this document could be cleaned up and made ready for publication by using any of the following three options: (i) Formally ask W3C if the document cited as [W3C-PUBRULES] is an appropriate specification of this relation type or if some other document exists or can be constructed within a reasonable (and fixed) period of time. If so, reference it normatively, producing an RFC only if the current state of the Link Relation registry requires that. Forget about extensions except insofar as they come through the process that produced this specification. (ii) Prepare and publish an Informational RFC that strictly describes the existing practice and says so. Publish a separate document, probably as Experimental, that proposes and argues for the extension. (iii) Modify this document to be _extremely_ clear about what is existing practice and what is the author's suggestion about an extension. For the latter, the change being made, the justification for it, and a risk analysis should be present and explicit. If IETF publication as an RFC is anticipated for any of those three options, the inconsistent language should be cleaned up; the Acknowledgments section completed;
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Thanks to everybody for discussion. I've sent a note to spec-prod list, which you may find at http://lists.w3.org/Archives/Public/spec-prod/2012JanMar/.html, and I'll notify you of the responses that I expect to receive before Thursday. Mykyta Yevstifeyev 2012/1/1 Bjoern Hoehrmann derhoe...@gmx.net: * Julian Reschke wrote: I'm almost with you. However, changing the actual definition and adding an additional post LC would be kind of surprising, wouldn't it? Among the goals of the Internet Standards Process are openness and fairness and I would find these principles grossly violated if the IESG would approve the document for publication with the proposed changes applied but without another Last Call. With another Last Call and if there is rough consensus in favour of the changes, and that'd include running code, then that's fine with me, regardless of whether an intention to publish an Internet-Draft as RFC is communicated to some obscure W3C mailing list, or who communicates such an intention. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ 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: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
2012/1/1 Bjoern Hoehrmann derhoe...@gmx.net: * Mykyta Yevstifeyev wrote: I'd like to seek consensus on separating the semantics of link relation for separate disclosure and a list thereof, correspondingly defining two link relations - 'disclosure' and 'disclosure-list'. You may see my edits made to Section 2 of the doc. below, which I'm proposing: 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI [RFC5988] MUST refer to a particular patent disclosure made with respect to the material being referenced by context IRI. 3. 'disclosure-list' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST designate a list of patent disclosures made with respect to the material being referenced by context IRI. As the doc. is in Last Call now, in order not to initiate a new one, please comment on these changes before January 6, so that I could know which version I should submit for IESG evaluation. I do not think you should (be able to) make such a change without a new Last Call, and I disagree with the separation. Reasons include that it's unclear which relation you use if you have one disclosure where many patents are disclosed; would that be disclosure because it's just one disclosure, or would it be a disclosure-list because many patents are disclosed? 'disclosure', because the semantics concern the patent disclosure, not the patent. On the German Wikipedia people are even used to flamewars concerning List articles that have no or just one item, where some ar- gue that you need at least two items to have a list. In this sense you could probably always use 'disclosure-list' in place of 'disclosure' if you think empty and single item lists are meaningful concepts. A list should be considered to be a list even if it is empty or has one entry, so we can use 'disclosure-list' here. Mykyta Yevstifeyev -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
2012/1/1 John C Klensin john-i...@jck.com: Hi. While I'm highly sympathetic to Thomas Roessler's position which I interpret as this needing (as a matter of courtesy and cooperation, if nothing else) affirmative signoff from the relevant parties in W3C, I would settle for any clear set of comments from them. But I think this also needs some examination in terms IETF relationships and process independent of the W3C-related issues. It is, IMO, entirely appropriate to publish a specification as Informational when it precisely describes some existing practice for the information of the community. We have a long history of doing that in what is now called the Independent and, when the specification bears some direct relationship to other IETF work, in the IETF stream. But this document, in the -00 version circulated for Last Call, is not such a precise, factual, description: it contains errors or misstatements (examples below) and it contains extensions beyond the existing practice that are not clearly identified and that, as far as I can tell, have not been deployed or tested. While I see no reason why they would not work, experience is the proper test of whether some particular approach or syntax is adequate. I believe that the IESG ought to take exceptional care with individual submissions, precisely because they are published in the IETF stream, requiring significant expertise or careful reading to determine whether they actually represent informed and competent IETF consensus. Against that test, this document is not ready for approval and RFC publication. Specific examples: (1) The second sentence of the Introduction begins This document specifies a new type of such relationship But this is not new: it has been around for years, as the next paragraph (and comments on the IETF list) indicate. It's new in context of being formally registered. (2) The last paragraph of the Introduction reads: This document is to formally register the 'disclosure' Link Relation Type with IANA and provide a permanent record on it for the Internet community. Additionally, it expands the sphere of this relation type to allow its use when referring to separate patent disclosures. So it registers the type (good, IMO); makes a permanent and public record --which the author believes W3C has failed to do (good, IMO); documents the existing practice (also good, IMO); and creates an untested extension (outside the scope of Informational publication of an existing practice, IMO). So do you propose dropping the semantics for separate disclosures and leaving the original W3C's? (3) There is no analysis at all of whether the compound use of this relation identifier (within a ul element) might confuse any existing implementations and, if so, how that confusion would play itself out. For example, we have learned the hard way in other areas that, when multiple instances of the same information-label appear with different values and without that being explicitly provided for in the specification, some implementations will use the first one and ignore the others, others will pick the last one and ignore the others, some will reject the construct entirely, and still others will try to somehow combine the fields. If we know what would happen here, the document doesn't say so. Without such an analysis, the statement of true belief in Security Considerations may be a little bit optimistic. (4) While it is not unusual for Acknowledgments sections to be updated during or after Last Call, an entry of TBD for the only contributors to the document make it impossible for the community to verify that the BCP78 requirements have been followed. TBD occurred because there were no comments received before LC; but now, I hope, this may be corrected. I think this document could be cleaned up and made ready for publication by using any of the following three options: (i) Formally ask W3C if the document cited as [W3C-PUBRULES] is an appropriate specification of this relation type or if some other document exists or can be constructed within a reasonable (and fixed) period of time. If so, reference it normatively, producing an RFC only if the current state of the Link Relation registry requires that. Forget about extensions except insofar as they come through the process that produced this specification. (ii) Prepare and publish an Informational RFC that strictly describes the existing practice and says so. Publish a separate document, probably as Experimental, that proposes and argues for the extension. (iii) Modify this document to be _extremely_ clear about what is existing practice and
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-27 07:52, Mykyta Yevstifeyev wrote: Hello, I'd like to seek consensus on separating the semantics of link relation for separate disclosure and a list thereof, correspondingly defining two link relations - 'disclosure' and 'disclosure-list'. You may see my edits made to Section 2 of the doc. below, which I'm proposing: 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI [RFC5988] MUST refer to a particular patent disclosure made with respect to the material being referenced by context IRI. 3. 'disclosure-list' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST designate a list of patent disclosures made with respect to the material being referenced by context IRI. As the doc. is in Last Call now, in order not to initiate a new one, please comment on these changes before January 6, so that I could know which version I should submit for IESG evaluation. ... I don't see a compelling reason to distinguish both. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Hello, I'd like to seek consensus on separating the semantics of link relation for separate disclosure and a list thereof, correspondingly defining two link relations - 'disclosure' and 'disclosure-list'. You may see my edits made to Section 2 of the doc. below, which I'm proposing: 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI [RFC5988] MUST refer to a particular patent disclosure made with respect to the material being referenced by context IRI. 3. 'disclosure-list' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST designate a list of patent disclosures made with respect to the material being referenced by context IRI. As the doc. is in Last Call now, in order not to initiate a new one, please comment on these changes before January 6, so that I could know which version I should submit for IESG evaluation. Thanks, Mykyta Yevstifeyev 2011/12/9 The IESG iesg-secret...@ietf.org: The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.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 ietf@ietf.org mailing lists by 2012-01-06. 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 specifies the 'disclosure' Link Relation Type. It designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation type is specified. The file can be obtained via http://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/ 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: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 13 December 2011 21:50 Julian Reschke julian.resc...@gmx.de wrote: On 2011-12-13 20:07, Mykyta Yevstifeyev (М. Євстіфеєв) wrote: ... Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. I have that - in source code. Maybe I should add in HTML source code? The latter sounds good. It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). And I have this as well, as I've introduced this extract with must look like. I'd like to see this confirmed by the W3C. Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. Well, it doesn't say anything interesting, and might confuse people to think this was an oversight in 5988. Just drop it. OK, I will. 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? Yes. I may change to: Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. to improve readability. OK. This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? I have: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List both lines are indented with 5 Courier white spaces, and so I think my explanation in parentheses is correct. Well, HTTP header fields start at column 0 in a message. Of course you can indent your examples, but my point was that if you indent the second line *more*, it would be valid. Like this: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List This is OK as well. Mykyta Yevstifeyev ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
2011/12/13 SM s...@resistor.net: At 11:07 13-12-2011, Mykyta Yevstifeyev wrote: This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. In the Introduction Section, the following sentence could be dropped: However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. The last paragraph of that section explains what the document is about. I've already done this, per Julian's comments. I suggest an editorial change in Section 2: Whenever the 'disclosure' relation is defined, the target IRI [RFC5998] MUST either Added. Quoting the example in Section 3: The following are the patent disclosures known at present made with respect to this specification: ula rel=disclosure href=http://patent.gov/8546987; U.S. Patent No. 8546987/a/ul ula rel=disclosure href=http://ipr.su/pat/98745-6; U.S.S.R. Patent No. 98745-6/a/ul ula rel=disclosure href=ftp://ftp.legal.va/a/patent3.pdf; Vatical City State Patent No. 3/a/ul If the IETF takes the security of the Vatican City seriously (there's a typo in the example), I suggest adding a .example at the end of the domain names. I'm fine with this. So I've changed this to: The following are the patent disclosures known at present made with respect to this specification: ula rel=disclosure href=http://patent.gov.example/8546987; U.S. Patent No. 8546987/a/ul ula rel=disclosure href=http://ipr.su.example/pat/98745-6; U.S.S.R. Patent No. 98745-6/a/ul ula rel=disclosure href=http://pat.va.example/a/patent3.pdf; Vatical City State Patent No. 3/a/ul Mykyta Yevstifeyev Regards, -sm ___ 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: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
11.12.2011 22:05, Julian Reschke wrote: Hi there, Hi Julian, feedback below: 1. Introduction RFC 5988 [RFC5988] defined a way of indicating relationships between resources on the Web. This document specifies a new type of such relationship - 'disclosure' Link Relation Type. It designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation is specified. s/-/- the/? Will fix. Active use of 'disclosure' relation type has been identified. The current version of W3C Publication Rules [W3C-PUBRULES], Bullet 36 of Section 5, defines that each W3C document must have the boilerplate referring to the page where one may find patent disclosures made with regard to such document. As W3C Publication Rules are applied to many documents, that might be under different patent policies, a number of variants of the mentioned boilerplate exist. However, the phrase W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. can be found in each of these variants. Publication Rules specify that, in the source code, it must look like: W3C maintains a a rel=disclosure href=...public list of any patent disclosures/a made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. I have that - in source code. Maybe I should add in HTML source code? It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). And I have this as well, as I've introduced this extract with must look like. Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? Yes. I may change to: Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. to improve readability. This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? I have: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List both lines are indented with 5 Courier white spaces, and so I think my explanation in parentheses is correct. Appendix A. Acknowledgments Thanks to Bjoern Hoehrmann for noticing that 'disclosure' relation is not properly specified and, correspondingly, initiating this work. The author would also like to acknowledge the contributions of TBD to this document. Who's this TBD guy? :-) You probably :-). Mykyta Yevstifeyev Best regards, Julian ___ Ietf mailing list
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
11.12.2011 22:14, Julian Reschke wrote: On 2011-12-11 21:05, Julian Reschke wrote: Hi there, feedback below: ... Forgot one more thing. The registry already contains the copyright link relation; maybe it would be good to explain who these are different. This is certainly what I should do. Thanks for feedback! 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: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-13 20:07, Mykyta Yevstifeyev (М. Євстіфеєв) wrote: ... Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. I have that - in source code. Maybe I should add in HTML source code? The latter sounds good. It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). And I have this as well, as I've introduced this extract with must look like. I'd like to see this confirmed by the W3C. Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. Well, it doesn't say anything interesting, and might confuse people to think this was an oversight in 5988. Just drop it. 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? Yes. I may change to: Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. to improve readability. OK. This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? I have: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List both lines are indented with 5 Courier white spaces, and so I think my explanation in parentheses is correct. Well, HTTP header fields start at column 0 in a message. Of course you can indent your examples, but my point was that if you indent the second line *more*, it would be valid. Like this: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
At 11:07 13-12-2011, Mykyta Yevstifeyev wrote: This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. In the Introduction Section, the following sentence could be dropped: However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. The last paragraph of that section explains what the document is about. I suggest an editorial change in Section 2: Whenever the 'disclosure' relation is defined, the target IRI [RFC5998] MUST either Quoting the example in Section 3: The following are the patent disclosures known at present made with respect to this specification: ula rel=disclosure href=http://patent.gov/8546987; U.S. Patent No. 8546987/a/ul ula rel=disclosure href=http://ipr.su/pat/98745-6; U.S.S.R. Patent No. 98745-6/a/ul ula rel=disclosure href=ftp://ftp.legal.va/a/patent3.pdf; Vatical City State Patent No. 3/a/ul If the IETF takes the security of the Vatican City seriously (there's a typo in the example), I suggest adding a .example at the end of the domain names. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-09 18:58, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.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 ietf@ietf.org mailing lists by 2012-01-06. 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. ... I think it would have been wise if the author actually had sent a review request to the link relation mailing list, first (see http://tools.ietf.org/html/rfc5988#section-6.2.1). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
11.12.2011 16:13, Julian Reschke wrote: On 2011-12-09 18:58, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.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 ietf@ietf.org mailing lists by 2012-01-06. 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. ... I think it would have been wise if the author actually had sent a review request to the link relation mailing list, first (see http://tools.ietf.org/html/rfc5988#section-6.2.1). Julian, I have: http://www.ietf.org/mail-archive/web/link-relations/current/msg00296.html ... and additionally even to apps-discuss: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03420.html 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: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-11 15:19, Mykyta Yevstifeyev (М. Євстіфеєв) wrote: 11.12.2011 16:13, Julian Reschke wrote: On 2011-12-09 18:58, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.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 ietf@ietf.org mailing lists by 2012-01-06. 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. ... I think it would have been wise if the author actually had sent a review request to the link relation mailing list, first (see http://tools.ietf.org/html/rfc5988#section-6.2.1). Julian, I have: http://www.ietf.org/mail-archive/web/link-relations/current/msg00296.html ... and additionally even to apps-discuss: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03420.html ... I haven't recognized that as a registration request, it would have been helpful to mark it as such in the subject line (again, see http://tools.ietf.org/html/rfc5988#section-6.2.1). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
11.12.2011 16:31, Julian Reschke wrote: On 2011-12-11 15:19, Mykyta Yevstifeyev (М. Євстіфеєв) wrote: 11.12.2011 16:13, Julian Reschke wrote: On 2011-12-09 18:58, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.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 ietf@ietf.org mailing lists by 2012-01-06. 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. ... I think it would have been wise if the author actually had sent a review request to the link relation mailing list, first (see http://tools.ietf.org/html/rfc5988#section-6.2.1). Julian, I have: http://www.ietf.org/mail-archive/web/link-relations/current/msg00296.html ... and additionally even to apps-discuss: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03420.html ... I haven't recognized that as a registration request, it would have been helpful to mark it as such in the subject line (again, see http://tools.ietf.org/html/rfc5988#section-6.2.1). By sending a message to link-relations list, I though it had been implied that I had sent a registration request independently of the title. Anyway, you, as an expert reviewer, may review the document during Last Call, and I don't think it should be a problem. Mykyta Yevstifeyev Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
--On Sunday, December 11, 2011 15:13 +0100 Julian Reschke julian.resc...@gmx.de wrote: I think it would have been wise if the author actually had sent a review request to the link relation mailing list, first (see http://tools.ietf.org/html/rfc5988#section-6.2.1). Julian, Rather than seeing more of these procedural messages go back and forth, let me agree with you about wise but note that there is nothing in the procedures that prevents Mykyta from asking for an IETF Last Call on the document first if he wants to. I would suggest -- with some confidence even without actual certainty-- that, if the Link-Review list, or even the Designated Expert, sent in a Last Call comment suggesting (and explaining why) that this proposal was wonderful, or that it was deeply flawed, the IESG would pay lots of attention to that. A review that would justify one of those conclusions --or asking the IESG to send the document back for revision and suggesting that the IETF list see no more Last Calls until there had been adequate discussion on the relevant mailing list -- would seem to me to be a more useful use of energy than questioning the procedural path. My one procedural comment to the IESG would be that approving this before there is a proper agreement to put the necessary bits in the registry would be inappropriate and, to use Julian's term, unwise. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Hi there, feedback below: 1. Introduction RFC 5988 [RFC5988] defined a way of indicating relationships between resources on the Web. This document specifies a new type of such relationship - 'disclosure' Link Relation Type. It designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation is specified. s/-/- the/? Active use of 'disclosure' relation type has been identified. The current version of W3C Publication Rules [W3C-PUBRULES], Bullet 36 of Section 5, defines that each W3C document must have the boilerplate referring to the page where one may find patent disclosures made with regard to such document. As W3C Publication Rules are applied to many documents, that might be under different patent policies, a number of variants of the mentioned boilerplate exist. However, the phrase W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. can be found in each of these variants. Publication Rules specify that, in the source code, it must look like: W3C maintains a a rel=disclosure href=...public list of any patent disclosures/a made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? Appendix A. Acknowledgments Thanks to Bjoern Hoehrmann for noticing that 'disclosure' relation is not properly specified and, correspondingly, initiating this work. The author would also like to acknowledge the contributions of TBD to this document. Who's this TBD guy? :-) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-11 21:05, Julian Reschke wrote: Hi there, feedback below: ... Forgot one more thing. The registry already contains the copyright link relation; maybe it would be good to explain who these are different. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.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 2012-01-06. 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 specifies the 'disclosure' Link Relation Type. It designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation type is specified. The file can be obtained via http://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/ 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