Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC

[John C Klensin]

--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

[Peter Saint-Andre]

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

[John C Klensin]

--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

[Mykyta Yevstifeyev]

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

[Julian Reschke]

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 Yevstifeyev]

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

[Thomas Roessler]

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

[Bjoern Hoehrmann]

* 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

[Thomas Roessler]

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

[Bjoern Hoehrmann]

* 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

[Thomas Roessler]

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

[John C Klensin]

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

[Bjoern Hoehrmann]

* 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

[Julian Reschke]

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

[Bjoern Hoehrmann]

* 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

[Bjoern Hoehrmann]

* 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

[John C Klensin]

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

[Mykyta Yevstifeyev]

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

[Mykyta Yevstifeyev]

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

[Mykyta Yevstifeyev]

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

[Julian Reschke]

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

[Mykyta Yevstifeyev]

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

[Mykyta Yevstifeyev]

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

[Mykyta Yevstifeyev]

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

[Mykyta Yevstifeyev (М. Євстіфеєв)]

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

[Mykyta Yevstifeyev (М. Євстіфеєв)]

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

[Julian Reschke]

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

[SM]

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

[Julian Reschke]

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

[Mykyta Yevstifeyev (М. Євстіфеєв)]

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

[Julian Reschke]

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

[Mykyta Yevstifeyev (М. Євстіфеєв)]

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

[John C Klensin]

--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

[Julian Reschke]

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

[Julian Reschke]

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]

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