Subject: [Ietf-and-github] Fwd: New Version Notification for draft-kwatsen-git-xiax-automation-00.txt

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Feb 2019 19:14:07 +0000

All,

I just posted a -00 for an idea I've been working on. 

    https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00 <https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00>

It only lightly touches `git` in its ability to use `git tag` to extract a document's next version
number, this being consistent with Martin's i-d-template work.  Still, I'm wondering if the
'git' WG might provide a home for this work, or if there is a better place for it.

I wish I could present this work in Prague but, unfortunately, I'm leaving Prague Thursday
morning.   I mentioned this before here: https://mailarchive.ietf.org/arch/msg/ietf-and-github/yqlmbElFCWtZfYAWtANiasTpTq8

Cheers,
Kent

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-kwatsen-git-xiax-automation-00.txt
> Date: February 25, 2019 at 1:59:00 PM EST
> To: "Kent Watsen" <[email-masked]>
> 
> 
> A new version of I-D, draft-kwatsen-git-xiax-automation-00.txt
> has been successfully submitted by Kent Watsen and posted to the
> IETF repository.
> 
> Name:		draft-kwatsen-git-xiax-automation
> Revision:	00
> Title:		eXtract or Insert artwork And source code to/from Xml (xiax)
> Document date:	2019-02-25
> Group:		Individual Submission
> Pages:		26
> URL:            https://www.ietf.org/internet-drafts/draft-kwatsen-git-xiax-automation-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-kwatsen-git-xiax-automation/
> Htmlized:       https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-kwatsen-git-xiax-automation
> 
> 
> Abstract:
>   This document describes motivations behind and solutions for tooling
>   to automate the extraction/insertion of artwork and source code to/
>   from `rfc2xml` documents.
> 
>   While much may appear to be working, the author believes that, in
>   order to be such automation to be maximally useful, it is necessary
>   to solicit broad input from the community (co-authors are welcomed,
>   both on the draft and the tool).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Feb 2019 22:52:13 +0000

Ugh, there's an embarrassing typo in the Abstract, so much for last-minute edits  ;)
   - I just posted a -01 to fix this

FWIW, an earlier version of the tool keyed off the presence of "originalSrc" attributes
to drive extractions and, by doing so, could extract content regardless if `xiax` or
"prep tool" inserted it.   Moving to the "xiax-block" lost this behavior, but I plan add
back support for also extracting artwork/sourcecode without an associated xiax-block
entry, thus able to extract all such content, regardless how placed, albeit without any
of the other automation support.

Kent

> On Feb 25, 2019, at 2:14 PM, Kent Watsen <[email-masked]> wrote:
> 
> All,
> 
> morning.   I mentioned this before here: https://mailarchive.ietf.org/arch/msg/ietf-and-github/yqlmbElFCWtZfYAWtANiasTpTq8 <https://mailarchive.ietf.org/arch/msg/ietf-and-github/yqlmbElFCWtZfYAWtANiasTpTq8>
> 
> Cheers,
> Kent
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: "Kent Watsen" <[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-kwatsen-git-xiax-automation-00.txt <https://www.ietf.org/internet-drafts/draft-kwatsen-git-xiax-automation-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-kwatsen-git-xiax-automation/ <https://datatracker.ietf.org/doc/draft-kwatsen-git-xiax-automation/>
>> Htmlized:       https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00 <https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-kwatsen-git-xiax-automation <https://datatracker.ietf.org/doc/html/draft-kwatsen-git-xiax-automation>
>> 
>> 
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Feb 2019 06:10:24 +0100

On 25.02.2019 20:14, Kent Watsen wrote:
> https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00
> 
> morning.   I mentioned this before here: 
> https://mailarchive.ietf.org/arch/msg/ietf-and-github/yqlmbElFCWtZfYAWtANiasTpTq8
> 
> Cheers,
> Kent

I notice that you seem to propose new extension attributes for stuff you 
can already do without. See, in particular,

https://greenbytes.de/tech/webdav/rfc7991.html#element.artwork.attribute.name

https://greenbytes.de/tech/webdav/rfc7991.html#element.sourcecode.attribute.name

https://greenbytes.de/tech/webdav/rfc7991.html#includingexternal

The following discussion about CODE BEGIN etc should also be interesting:

<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/8>

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 26 Feb 2019 12:49:20 +0100

Hi Kent,

On 2019-02-25 23:52, Kent Watsen wrote:
> FWIW, an earlier version of the tool keyed off the presence of
> "originalSrc" attributes to drive extractions and, by doing so, could
> extract content regardless if `xiax` or "prep tool" inserted it.
> Moving to the "xiax-block" lost this behavior, but I plan add back
> support for also extracting artwork/sourcecode without an associated
> xiax-block entry, thus able to extract all such content, regardless
> how placed, albeit without any of the other automation support.

For both xml2rfc version 2 <artwork>, and version 3 <sourcecode> (I don't
think you should touch v3 <artwork>, but that's a separate discussion),
I believe you should be using the "name" attribute, not the 
"src"/"originalSrc" or xiax:src attributes to provide the file names
to export to; see https://tools.ietf.org/html/rfc7991#section-2.48.2.

The "name" attribute on <artwork> is also supported in the v2 schema.

If there are any specific reasons why you've not used "name" attribute,
which is provided with the intention of being used by extraction tools,
we should have a discussion and understand why.

----

Some additional comments on the draft (I looked at -01):

|  
|  5.  Updates to RFC 7991
|  
|     This section is just a placeholder for now, but it is expected that
|     [RFC7991] will need to be modified in order to support some of this
|     work.
|  
|     At a minimum, [RFC7991] should be updated to support attributes from
|     other namespaces, such that the `rfc2xml` tool would neither process
|     nor discard them.

Blanket acceptance of unknown attributes would make validation of schema
attributes go away.  I'm fine with discussing specific new attributes for
specific elements, but not a blanket acceptance of any attributes as valid
in the input.  Accepting wildcard attributes in specific namespaces for
<sourcecode> in the v3 grammar seems doable (I've just tested a grammar
tweak for that).  I think this is what you're after, but the text in the
draft seems a bit too open-ended.

|  7.  Previous Work
...
|     o  The RFC Submit [submit] tool has been modified to test YANG
|        modules contained within I-Ds, and the resulting document page in
|        Datatracker [datatracker] displays a new "Yang Validation" field
|        containing a varying color yin-yang symbol (green if no errors,
|        red if errors) along with counts.  This tool is okay for what it
|        is, but it neither aids authors between updates nor validates
|        anything beyond YANG modules.

Additional info: The datatracker submission checking for YANG modules
was written to be easily extended, exactly for the purpose of adding
additional checkers in the future (I'm mentioning this as an additional
point in support of generalizing the tool work in this area).

|  10.  Security Considerations
|  
|  10.1.  Automated Execution of Arbitrary Scripts
...
|     o  Allow arbitrary scripts, but don't execute them automatically when
|        a document is extracted.  This solution is appealing as it still
|        ensures these scripts were executed on the author's computer at
|        time of construction, and the scripts themselves can be extracted
|        and audited on the reviewer's computer.  If desired, after
|        auditing a script, a reviewer could choose to manually execute it
|        on their own computer.

Creating a generalized solution that would permit packaging of the verification
code in the document seems sooo tempting.  But we've seen time and again that
if you make it possible to automate execution of arbitrary code, it will be
expanded to actually do the automation by someone, and then used by bad actors
down the road. -1.

|  
|     o  Don't allow arbitrary scripts but, instead, support parameterized
|        files that declare all the information necessary to construct the
|        command(s) necessary to generate derived views and/or validate
|        inclusions.

I like this better, but it's a much larger apparatus.  It might mean building
a registry of validation tools (for yang, the state of the art is such
that it seems feasible, but for other content that might not be so easy).

I think it's worth exploring, in any case.

Best regards,

        Henrik

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Feb 2019 16:24:54 +0000

Hi Julian,

> I notice that you seem to propose new extension attributes for stuff you can already do without. See, in particular,
> 

Yes, I was originally using the "name" attribute, but then I found that prep tool was using "originalSrc",
which made more since to me, since the goal is to capture the entire path (more than just the name).

> https://greenbytes.de/tech/webdav/rfc7991.html#includingexternal <https://greenbytes.de/tech/webdav/rfc7991.html#includingexternal>

I'm familiar with XInclude, but note that more than just including a file is going on (e.g., date substitutions,
content generation, validation, etc.).

> <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/8>

I hadn't seen this issue before, but I did see Henrik's comments about markers in 
draft-levkowetz-xml2rfc-v3-implementation-notes.  FWIW, the "xiax:markers" attribute
is primarily only to support xml2rfc v2 documents; v3 documents can just use the built-in
"markers" attribute.

That said, I think that markers are, in general, a mistake.  That they were only put their
for tools scrapping plain-text documents.   Assuming tools extract from XML, then no
markers are needed, neither for framing (to aid the scraping process) or for capturing
the file's name (which is better served by the aforementioned "name" attribute.

Kent

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Feb 2019 17:33:07 +0100

> the file's name (which is better served by the aforementioned "name" 

The original reason for "CODE BEGINS" etc was for licensing (to clarify 
that part of the content is considered to be a "code component").

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 26 Feb 2019 17:47:12 +0100

> that part of the content is considered to be a "code component").

No, it was not.  The original reason was to delimit code for other purposes.
The association with licencing came later.

	Henrik

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Feb 2019 16:52:36 +0000

> The original reason for "CODE BEGINS" etc was for licensing (to clarify that part of the content is considered to be a "code component").

Perhaps and, if so, then the markers may still have a purpose.   

That said, I only know the markers coming from https://tools.ietf.org/html/rfc8407#section-3.2 <https://tools.ietf.org/html/rfc8407#section-3.2>, which came from https://tools.ietf.org/html/rfc6087#section-3.1 <https://tools.ietf.org/html/rfc6087#section-3.1>.   As the co-chair and shepherd for these drafts, I assure you that my limited understanding for the original motivation is correct.   It's not intended to have any relationship to copyrights, though RFC6087 conflates both a module-level copyright (inside the YANG module) and markers (outside the YANG module) in Section 3.1, which we de-conflicted in RFC8407.

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 26 Feb 2019 17:56:23 +0100

Hi Kent,

On 2019-02-26 17:52, Kent Watsen wrote:
> 
>> The original reason for "CODE BEGINS" etc was for licensing (to
>> clarify that part of the content is considered to be a "code
>> component").
> 
> That said, I only know the markers coming from
> https://tools.ietf.org/html/rfc8407#section-3.2
> <https://tools.ietf.org/html/rfc8407#section-3.2>, which came from
> https://tools.ietf.org/html/rfc6087#section-3.1
> <https://tools.ietf.org/html/rfc6087#section-3.1>.

Just so.

> As the co-chair
> and shepherd for these drafts, I assure you that my limited
> understanding for the original motivation is correct.   It's not
> intended to have any relationship to copyrights, though RFC6087
> conflates both a module-level copyright (inside the YANG module) and
> markers (outside the YANG module) in Section 3.1, which we
> de-conflicted in RFC8407.

Good so.

	Henrik

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Feb 2019 12:19:38 -0500

RFC 5377 section 4.3 calls out that code has different copyright grants 
than other parts of the document.  It describes various examples of 
code, and then asks the IETF Trust to specify textual marking for code 
so that authors can be explicit and can mark things that may not be 
obvious by the examples.

So it goes back a lot earlier than 6087.
And as far as I know goes back to before there was any tooling support 
for the markings.

Yours,
Joel

On 2/26/19 11:52 AM, Kent Watsen wrote:
>> clarify that part of the content is considered to be a "code component").
> 
> 
> https://tools.ietf.org/html/rfc8407#section-3.2, which came from 
> https://tools.ietf.org/html/rfc6087#section-3.1.   As the co-chair and 
> shepherd for these drafts, I assure you that my limited understanding 
> for the original motivation is correct.   It's not intended to have any 
> relationship to copyrights, though RFC6087 conflates both a module-level 
> copyright (inside the YANG module) and markers (outside the YANG module) 
> in Section 3.1, which we de-conflicted in RFC8407.
> 
> Kent
> 
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 26 Feb 2019 18:25:28 +0100

Hi Joel,

> And as far as I know goes back to before there was any tooling support 

Indeed.  And later, when there was discussion about possible code markings,
I proposed that we use the <CODE BEGINS>, <CODE ENDS> introduced by RFC 6087,
rather than inventing something new.

Regards,

	Henrik

> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Feb 2019 19:03:51 +0100

On 26.02.2019 17:47, Henrik Levkowetz wrote:
> The association with licencing came later

The oldest RFC I see containing "CODE BEGINS" is RFC 5403, dated 
February 2009.

The oldest "code components" list mentioned on 
<https://trustee.ietf.org/trust-legal-provisions.html> is dated November 
2008.

Best regards, Julian

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 26 Feb 2019 18:05:20 +0000

I believe the first mentioning of code markers was in the attached email, which was on the IPR WG mailing list on a thread in the context of the copyright RFCs (BCP78).
Stephan

On 2/26/19, 09:25, "Ietf-and-github on behalf of Henrik Levkowetz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Joel,

    
    Regards,
    
    	Henrik
    
    >> in Section 3.1, which we de-conflicted in RFC8407.

Subject: Re: Legal Provisions Relating to IETF Documents
From: Brian E Carpenter <[email-masked]>
To: Ed Juskevicius <[email-masked]>
Cc: [email-masked]
Date: Mon, 7 Jul 2008 10:42:41 +1200
List-Id: IPR-WG <ipr-wg.ietf.org>

Hi,

> (y)  all IETF legends, legal notices and indications of 
> authorship contained in the original IETF RFC must also be 
> included where more than <one half> of an IETF RFC is 
> reproduced in a single document or series of related 
> documents.

A half seems like rather a high limit; a short RFC can be
almost 50% boilerplate anyway. I realise we need an objective
rule, so can I suggest "one fifth"?

> For ease of reference, Code Components in IETF RFCs may be 
> designated by <LABEL>.

How about ...may be enclosed between the marks "<CODE BEGIN>"
and "<CODE END>" ?

> a. General Notice for Internet-Drafts. The following text 
> must appear <at the beginning> of each Internet-Draft:

and

> c. Copyright and License Notice. The following notice must be
> contained at the beginning of each IETF Document (including
> RFCs and Internet-Drafts):

"At the beginning" is not good enough for automated checkers.
I suggest "on the first page" in both cases.

    Brian
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Feb 2019 18:05:33 +0000

Hi Henrik,

> think you should touch v3 <artwork>, but that's a separate discussion),

I can see why you might say that, assuming the primary value-add is build-time
validation, but note also that the "xiax:gen" attribute is used to dynamically 
*generate artwork*, which extends to v3 artwork (including SVGs) as well.

> we should have a discussion and understand why.

As I just wrote Julian, `xiax` was using the "name" attribute originally, but 
it needed to store the file's entire path (not just its name), so that the same
directory structure can be recreated during extraction, so that paths found
in the validation/generation scripts are valid, and hence round-tripping works.
Note that authors tend to place various inclusion files in subdirectories so
as to keep their document's top-level directory clean, so paths are fairly 
common.  

But I also saw that prep-tool didn't auto-set the "name" attribute and, as
`xiax` is effectively a preptool too, I figured it shouldn't muck with the "name"
attribute either.   That said, I think that it would make sense for `xiax` to
also set the "name" attribute, to be just the "basename" component of the
filepath string, as this must be intended 99.9% of the time...

FWIW, `xiax` originally tried to set the "originalSrc" attribute, which was
nice and clean but, unfortunately, `xml2rfc` didn't accept it.  That's when
"xiax-block" came to be, which would be total overkill if it were for just 
this single purpose, but now xiax-block is being used to store much more
metadata than the original "src" value, so I'm happy the switch was made.

As a further side note, the original plan was to store all the per-element
metadata as a bunch of "xiax" prefixed attributes in each element.  While
this would work, it would be ugly and difficult on the copy editors.  For
instance, looking at the "yang-data xiax-block" in
https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.3.1 <https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.3.1>,
note how the per-inclusion "src" and "gen" elements are hierarchical and
each can include whole files.   If per-element "xiax" prefixed attributes were
used, they would wind up being large/ugly base64-encoded blobs.  Having
one large block at the end helped keep things clean in the body of the
document.

> draft seems a bit too open-ended.

I appreciate your concern but, in my effort to understand better, what issue
is there for random-prefixed elements/attributes appearing, if the default
processing ignores them all (other than not discarding them)?

Tying in my previous comment, having the xiax-block at the end where it is
out of the way seems good, but I worry about it being stored as an XML 
comment.  It seems that trepidatious luck is in play that comments are not
discarded.  At least, I'm unaware of any statement that XML comments
are guaranteed to be preserved.  In lieu of such statement being made,
it seems that it might be safer to use a <xiax:block> element just before
the close of the </rfc> tag but, this assumes a guarantee that random
prefixed elements won't be discarded either...

> point in support of generalizing the tool work in this area).

Good to know!    And, as I've mentioned to you in a private thread before,
I hope to join you at the Code Sprint in Prague to see about integrating
some of this work.

> expanded to actually do the automation by someone, and then used by bad actors

As a hyper-paranoid Security person, I'm very much aligned with your thinking
here.  That said, as the above quoted text states, what harm is there is the 
scripts are *NOT* executed automatically on extraction, that it would require
a manual/explicit action and, presumably, only then after reviewing the script
for such shenanigans?   The lure is pretty strong...

> that it seems feasible, but for other content that might not be so easy).

This approach is the only one that `xiax` supports now.   While I do think the
other approach has merit, it seemed important to first test how feasible this
approach would be.  Yes, code needs to be added for each new content-type  
(https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.2 <https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.2>).
And, even in the world of YANG, there's the issue of which YANG-tools (e.g.,
pyang, yanglint, etc) to support and to what extent.

> I think it's worth exploring, in any case.

Yes, exactly, nothing is locked down as of yet, plenty of opportunity for 
mid-course corrections.

Cheers,
Kent

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Feb 2019 19:12:51 +0100

> rather than inventing something new.

Those were introduced much earlier, and exactly for the reason I stated. 
That's at least how I read the historic documents, and it also matches 
my memory.

But wait, we even discussed it on xml2rfc - see 
<https://mailarchive.ietf.org/arch/msg/xml2rfc/7jfoO9KlNkiASuztADbtB9cmHew>, 
dated September 2009.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Feb 2019 19:16:15 +0100

> <https://mailarchive.ietf.org/arch/msg/xml2rfc/7jfoO9KlNkiASuztADbtB9cmHew>, 

...and 
<https://github.com/reschke/xml2rfc/commit/63e9cb5a6a30ce03369ce36f0e47bea4e40afc87>.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 26 Feb 2019 19:37:37 +0100

Hi Kent,

> *generate artwork*, which extends to v3 artwork (including SVGs) as well.

Ahh.  Point.  Yes.

> as to keep their document's top-level directory clean, so paths are fairly 

But there's no limitation on the "name" attribute that would exclude using
a relative path, that I'm aware of?

> filepath string, as this must be intended 99.9% of the time...

Mmm.  It seems to me that for xiax, all the generation, inclusion and
extraction purposes fit within what was the intended use of "name", except
that you'd want to set "src" if at some point the end products of external
tools processing would be a not-standalone .XML file dependent on external
files which were intended to be included by xml2rfc or an equivalent tool.

But given that you've worked with this more, I believe you have a better
understanding of what's needed -- what I'm trying to achieve here is to
separate concerns, trying to get to the point where we don't have multiple
interrelated attributes; instead having clearly separate ones, with
distinct purposes and effects.

> metadata than the original "src" value, so I'm happy the switch was made.

Ok, I can see that.

> As a further side note, the original plan was to store all the
> per-element metadata as a bunch of "xiax" prefixed attributes in each
> element. While this would work, it would be ugly and difficult on the
> copy editors. For instance, looking at the "yang-data xiax-block" in 
> https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.3.1
> <https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.3.1>,
> each can include whole files. If per-element "xiax" prefixed
> attributes were used, they would wind up being large/ugly
> base64-encoded blobs. Having one large block at the end helped keep
> things clean in the body of the document.

Ack, makes sense.

> processing ignores them all (other than not discarding them)?

Mainly expressing this in the grammar in such a way that it doesn't preclude
validation of the base schema, and keeps the grammar bounded.

There's also a secondary wish to capture sensible requirements, generalising
them, and making them available in the base vocabulary, eventually, in order
to enrich it over time.

> are guaranteed to be preserved.

Umm.  Right.  There has been several times when changes in the code has led
to upsets with comments, and I've had to take care to preserve comments, even
if it caused the code to become slightly more complex.

> In lieu of such statement being made,

Ack.  But as I mentioned, I'm not opposed to adding specific namespaces
attributes (and possibly even elements) in selected places -- it's the
unboundedness of permitting any elements and any attributes with any
namespace that makes me uncomfortable.

> I hope to join you at the Code Sprint in Prague to see about integrating

Ack :-)

> for such shenanigans?   The lure is pretty strong...

That you would not run embedded scripts automatically won't prevent others
from building such automation, if we build in features to embed scripts
intended to be run for validation, in the first place.

I'm sure everybody who's originally made it possible to put executable code
into .doc, .pdf, etc. would be horrified at what people have done with the
capability later.  We should have learnt that lesson by now ,:-}

> (https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.2
> <https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00#appendix-B.2>).

Ack.

> Yes, exactly, nothing is locked down as of yet, plenty of opportunity for 

Ack.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 26 Feb 2019 19:48:18 +0100

Hi Stephan,

On 2019-02-26 19:05, Stephan Wenger wrote:
> I believe the first mentioning of code markers was in the attached
> email, which was on the IPR WG mailing list on a thread in the
> context of the copyright RFCs (BCP78).
> Stephan

I believe you're right.

The first use in a draft could be draft-ietf-nfsv4-minorversion1-dot-x-10.txt,
from December 3, 2008, which would be after Brian's proposal.  I thought I'd
seen it in use earlier, but it seems I was wrong.

	Henrik

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Feb 2019 19:47:27 +0000

Hi Henrik,

Just responding to your comment about the "name" attribute (all your other comments were on the level).

While RFC 7991's description of the "name" attribute is compellingly close to the intended need, it doesn't explicitly state that "name" MAY or MUST NOT include relative directory paths.  My naive reading/understanding is that the "name" is just the name of the file itself, the so called "basename" of a complete filepath value.    At least, having "name" be defined to have this concrete purpose seems to have cross-cutting value.   

My purpose seems twisted by comparison, to the extent that I question if any other tool would want or need to know an inclusion's original filepath value.   On the other hand, "originalSrc" is semantically perfect for my needs.  Let me turn this around and ask, why does preptool use "originalSrc" as opposed to "name" and, that being the case, how is it any different for xiax?

Regards,
Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 26 Feb 2019 21:12:18 +0100

Hi Kent,

On 2019-02-26 20:47, Kent Watsen wrote:
> While RFC 7991's description of the "name" attribute is compellingly
> close to the intended need, it doesn't explicitly state that "name"
> MAY or MUST NOT include relative directory paths. My naive
> reading/understanding is that the "name" is just the name of the file
> itself, the so called "basename" of a complete filepath value. At
> least, having "name" be defined to have this concrete purpose seems
> to have cross-cutting value.
> 
> My purpose seems twisted by comparison, to the extent that I question
> if any other tool would want or need to know an inclusion's original
> filepath value. On the other hand, "originalSrc" is semantically
> perfect for my needs. Let me turn this around and ask, why does
> preptool use "originalSrc" as opposed to "name" and, that being the
> case, how is it any different for xiax?

I don't have information beyond what's given in RFC 7991 and RFC 7998,
but in my mind the distinction is this:  The "src" and "originalSrc"
attributes are for the use of the preptool when moving external sources
into the xml file for the purpose of having one single archival entity
(file).  There is no semantic defined for reversing this.

Unfortunately, item 1 and 4 in Section 5.5.1 of RFC 7998[1] seems to set
up a situation where the "src" value will be moved to "originalSrc" in
some cases and not in others, and where pre-existence of "orgiginalSrc"
will change the behaviour.  This makes it unintended effects possible if
other tools also use the "originalSrc" value.  (Mmm.  I think we need to
revisit this part of RFC 7998 to make the conditions under which "src",
"originalSrc", or both will exist).

On top of this, Section 5.6.5 of RFC 7998 [2] specifies that "originalSrc"
be removed as part of publication; and Section 5.5.1 specifies that "src"
will be removed (in some?? cases) when "originalSrc" is filled in, which
leaves you with neither "src" or "originalSrc" in the published document...

I'd be happiest if other tools did not touch "originalSrc", and only
used "src" in order to point at external documents for inclusion by
xml2rfc.  That would avoid tool interdependencies.

We then need to either make "name" useful for your purpose, or provide
another way (possibly an xiax:name attribute) that will do.

Best regards,

	Henrik

[1]  https://tools.ietf.org/html/rfc7998#section-5.5.1
[2]  https://tools.ietf.org/html/rfc7998#section-5.6.5