Hi Kyle,
I am fine with splitting the I-D along those lines, although I have
just published a revision that separates the two into independent
sections but keeps it in one I-D. Just as an author, I am interested
first in better understanding the process by which we can land RFCs
for the two parts. Please advise if you can suggest how we move
forward from here.
For now, I hope you would be interested in reviewing the new I-D
revision. I am sure there is a lot of existing implementation
experience to apply and look forward to your and others' contributions.
Nikunj
http://o-micron.blogspot.com
On Jun 5, 2009, at 10:51 AM, Kyle Marvin wrote:
It seems unwise to consider two separate I-Ds - one for specifying
new link @rel values and another to deal with in-lining. Will it buy
us anything in the IETF process?
It would get us a clear model for doing inlining that's valid beyond
the specific use case of hierarchy which would be more useful to us
since we don't have a specific need for the hierarchy I-D; as
someone else stated earlier, we have many types of relations where
inlining would be beneficial so the specifics of the spec is too
narrow to support what we need.
Would you be interested in seeing this get on the experimental track
so that when it is time to consider a revision of Atom the
experience accumulated by then can be used to propose something
along standards track?
I'm not opposed but if this is considered to be prior art that will
drive how inlining should be done more generally, then I think the
net effect (read as "the hoops you will have to jump through to get
consensus") are going to be the same whether the inlining
functionality is joined or split off so why not get the general
solution's benefit for the effort.
It could be there are aspects of this decision I'm missing. I
understand that what I'm asking for is more work for you (or
someone) and I'm sympathetic to that.
