Subject: [Id-event] Issue Shared by Poll and Push Specs: Massive Duplication

From: Mike Jones <[email-masked]>
Date: Wed, 18 Jul 2018 21:53:46 +0000

Massive Duplication Across Poll and Push Specs

  *   Content of 6 of 7 top-level sections in both specs duplicated
  *   Push source is 708 lines, poll is 984 lines
     *   572 of these lines are identical
     *   81% identical for push, 58% identical for poll
Problems with Duplication

  *   Not perfectly duplicated
     *   Edits to common text have already been inconsistently applied in several cases
     *   Requires manual editor actions to keep in sync
     *   Sometimes unclear which divergences intentional
  *   Some normative data structures duplicated
     *   For instance, error values defined twice
     *   Will they be kept in sync?
     *   Will they live in a common registry?
     *   Which will be authoritative?
Assertion: Current Organization Untenable

  *   Massive duplication creates consistency nightmare for editors
     *   Manual steps to keep common text consistent
  *   Massive duplication creates significant work for reviewers
     *   Having to figure out what's the same and what's different and try to understand why
  *   Massive duplication will confuse implementers
     *   Having to figure out what's the same and what's different and try to understand why
Possible Solutions

  *   Move to three delivery specs
     *   One for common pieces
     *   One for only push-specific pieces
     *   One for only poll-specific pieces
  *   Move to one delivery spec
     *   All text occurs only once
     *   Push-specific pieces in one section
     *   Poll-specific pieces in a different section
     *   Note: Both mechanisms could still be optional
     *   I believe this will be easier for all to understand
Discussion

  *   As an editor, I'm not prone to fix problems in duplicated text until we solve the duplication problem
     *   Unreasonable to ask us to do everything twice
  *   Data gathering
     *   Who has reviewed both specs?
     *   What was your experience reviewing them?
  *   How should we solve the duplication problem?
     *   Should we have one or three specs?

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Jul 2018 17:59:47 -0400

There is also the choice of 2 documents. If one of the docs is required to
be implemented, then the content could be in that spec, and the other spec
could refer to that content.

Personally, I hate having to read a large set of different documents to
figure out how to do something.

On Wed, Jul 18, 2018 at 5:53 PM, Mike Jones <
Michael.Jones=[email-masked]> wrote:

> *Massive Duplication Across Poll and Push Specs*
>
>    - Content of 6 of 7 top-level sections in both specs duplicated
>    - Push source is 708 lines, poll is 984 lines
>       - 572 of these lines are identical
>       - 81% identical for push, 58% identical for poll
>
> *Problems with Duplication*
>
>    - Not perfectly duplicated
>       - Edits to common text have already been inconsistently applied in
>       several cases
>       - Requires manual editor actions to keep in sync
>       - Sometimes unclear which divergences intentional
>    - Some normative data structures duplicated
>       - For instance, error values defined twice
>       - Will they be kept in sync?
>       - Will they live in a common registry?
>       - Which will be authoritative?
>
> *Assertion: Current Organization Untenable*
>
>    - Massive duplication creates consistency nightmare for editors
>       - Manual steps to keep common text consistent
>    - Massive duplication creates significant work for reviewers
>       - Having to figure out what’s the same and what’s different and try
>       to understand why
>    - Massive duplication will confuse implementers
>       - Having to figure out what’s the same and what’s different and try
>       to understand why
>
> *Possible Solutions*
>
>    - Move to three delivery specs
>       - One for common pieces
>       - One for only push-specific pieces
>       - One for only poll-specific pieces
>    - Move to one delivery spec
>       - All text occurs only once
>       - Push-specific pieces in one section
>       - Poll-specific pieces in a different section
>       - Note: Both mechanisms could still be optional
>       - *I believe this will be easier for all to understand*
>
> *Discussion*
>
>    - As an editor, I’m not prone to fix problems in duplicated text until
>    we solve the duplication problem
>       - Unreasonable to ask us to do everything twice
>    - Data gathering
>       - Who has reviewed both specs?
>       - What was your experience reviewing them?
>    - How should we solve the duplication problem?
>       - Should we have one or three specs?
>
>
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 18 Jul 2018 22:06:41 +0000

We can’t require that everyone implement an RFC.  Whether to do so is always a choice.

In the two RFCs case, even though neither would be required, one could contain all the common content and the other reference it.  Some of that was done between JWS [RFC 7515] and JWE [RFC 7516], for example, to remove duplication that had been present at one point.

I agree with you that having to read a large set of documents is suboptimal.  As I see it, one would be better than two, which would be better than three.

                                                       -- Mike

From: Dick Hardt <[email-masked]>
Sent: Wednesday, July 18, 2018 6:00 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [Id-event] Issue Shared by Poll and Push Specs: Massive Duplication

There is also the choice of 2 documents. If one of the docs is required to be implemented, then the content could be in that spec, and the other spec could refer to that content.

Personally, I hate having to read a large set of different documents to figure out how to do something.

On Wed, Jul 18, 2018 at 5:53 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc..ietf.org<mailto:Michael.Jones=[email-masked]>> wrote:
Massive Duplication Across Poll and Push Specs

     *   572 of these lines are identical
     *   81% identical for push, 58% identical for poll
Problems with Duplication
·        Not perfectly duplicated
·        Edits to common text have already been inconsistently applied in several cases
·        Requires manual editor actions to keep in sync
·        Sometimes unclear which divergences intentional
·        Some normative data structures duplicated
·        For instance, error values defined twice
·        Will they be kept in sync?
·        Will they live in a common registry?
·        Which will be authoritative?
Assertion: Current Organization Untenable
·        Massive duplication creates consistency nightmare for editors
·        Manual steps to keep common text consistent
·        Massive duplication creates significant work for reviewers
·        Having to figure out what’s the same and what’s different and try to understand why
·        Massive duplication will confuse implementers
·        Having to figure out what’s the same and what’s different and try to understand why
Possible Solutions

     *   One for common pieces
     *   One for only push-specific pieces
     *   One for only poll-specific pieces
·        Move to one delivery spec
·        All text occurs only once
·        Push-specific pieces in one section
·        Poll-specific pieces in a different section
·        Note: Both mechanisms could still be optional
·        I believe this will be easier for all to understand
Discussion
·        As an editor, I’m not prone to fix problems in duplicated text until we solve the duplication problem
·        Unreasonable to ask us to do everything twice
·        Data gathering
·        Who has reviewed both specs?
·        What was your experience reviewing them?
·        How should we solve the duplication problem?
·        Should we have one or three specs?

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Jul 2018 18:59:56 -0400

There is an acronym I am forgetting that said about what was minimally
required to implement to be compliant. I am likely using the wrong words.
There was concern from implementors that they would have to implement both
"push" and "poll" if both are in the same document, and many implementors
only expected to implement one method.

*if* one is only implementing one, then two docs are better than one, as
you only have to read what you are implementing.

On Wed, Jul 18, 2018 at 6:06 PM, Mike Jones <[email-masked]>
wrote:

> In the two RFCs case, even though neither would be required, one could
> contain all the common content and the other reference it.  Some of that
> was done between JWS [RFC 7515] and JWE [RFC 7516], for example, to remove
> duplication that had been present at one point.
>
>
>
> I agree with you that having to read a large set of documents is
> suboptimal.  As I see it, one would be better than two, which would be
> better than three.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt <[email-masked]>
> *Sent:* Wednesday, July 18, 2018 6:00 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Id-event] Issue Shared by Poll and Push Specs: Massive
> Duplication
>
>
>
> On Wed, Jul 18, 2018 at 5:53 PM, Mike Jones <Michael.Jones=40microsoft.
> com@dmarc..ietf.org <Michael.Jones=[email-masked]>> wrote:
>
> ·        *I believe this will be easier for all to understand*
>
> *Discussion*
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 18 Jul 2018 23:17:53 +0000

The solution to the worry that people would have to implement both is to explicitly say in the single draft that a conforming implementation can implement pull, poll, or both.  I doesn’t have to be any harder than that.

From: Id-event <[email-masked]> On Behalf Of Dick Hardt
Sent: Wednesday, July 18, 2018 7:00 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [Id-event] Issue Shared by Poll and Push Specs: Massive Duplication

There is an acronym I am forgetting that said about what was minimally required to implement to be compliant. I am likely using the wrong words. There was concern from implementors that they would have to implement both "push" and "poll" if both are in the same document, and many implementors only expected to implement one method.

*if* one is only implementing one, then two docs are better than one, as you only have to read what you are implementing.

On Wed, Jul 18, 2018 at 6:06 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
We can’t require that everyone implement an RFC.  Whether to do so is always a choice.

                                                       -- Mike

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 18, 2018 6:00 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Issue Shared by Poll and Push Specs: Massive Duplication

  *   Content of 6 of 7 top-level sections in both specs duplicated
  *   Push source is 708 lines, poll is 984 lines
·        572 of these lines are identical
·        81% identical for push, 58% identical for poll
Problems with Duplication
•        Not perfectly duplicated
•        Edits to common text have already been inconsistently applied in several cases
•        Requires manual editor actions to keep in sync
•        Sometimes unclear which divergences intentional
•        Some normative data structures duplicated
•        For instance, error values defined twice
•        Will they be kept in sync?
•        Will they live in a common registry?
•        Which will be authoritative?
Assertion: Current Organization Untenable
•        Massive duplication creates consistency nightmare for editors
•        Manual steps to keep common text consistent
•        Massive duplication creates significant work for reviewers
•        Having to figure out what’s the same and what’s different and try to understand why
•        Massive duplication will confuse implementers
•        Having to figure out what’s the same and what’s different and try to understand why
Possible Solutions
·        Move to three delivery specs
·        One for common pieces
·        One for only push-specific pieces
·        One for only poll-specific pieces
•        Move to one delivery spec
•        All text occurs only once
•        Push-specific pieces in one section
•        Poll-specific pieces in a different section
•        Note: Both mechanisms could still be optional
•        I believe this will be easier for all to understand
Discussion
•        As an editor, I’m not prone to fix problems in duplicated text until we solve the duplication problem
•        Unreasonable to ask us to do everything twice
•        Data gathering
•        Who has reviewed both specs?
•        What was your experience reviewing them?
•        How should we solve the duplication problem?
•        Should we have one or three specs?

---

From: Adam Dawes <[email-masked]>
Date: Wed, 18 Jul 2018 22:38:39 -0700

On Wed, Jul 18, 2018 at 4:18 PM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> The solution to the worry that people would have to implement both is to
> explicitly say in the single draft that a conforming implementation can
> implement pull, poll, or both.  I doesn’t have to be any harder than that.
>

I believe one of the other reasons for separating out the drafts now was
that the push spec was more mature and there was high demand for it with
RISC. Would it be reasonable to have one spec with three sections and when
two of the three sections have WG consensus we cut a draft of it for
ratification and then a branch of it with the third sections continues and
then when consensus of that is reached we seek ratification on the full
version?

> *From:* Id-event <[email-masked]> *On Behalf Of *Dick Hardt
> *Sent:* Wednesday, July 18, 2018 7:00 PM
> Michael.Jones=40microsoft.com@dmarc..ietf.org
> <Michael.Jones=[email-masked]>> wrote:
>

-- 
Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 19 Jul 2018 15:02:36 +0000

To some extent that duplication is deliberate. The HTTP Push draft was created by starting from the combined draft and stripping out all references to HTTP Poll, and vice-versa for the HTTP Poll draft. This was done to minimize the risk of introducing unintentional normative changes when splitting the draft. I’d originally intended these -00 drafts to live just long enough for the WG to confirm that they correctly reflect the normative content of the original, at which point we could follow with revisions to strip out unnecessary content (which I think there is much of). Unfortunately I didn’t drive that process, so we’re still sitting at step 0.

With that in mind, let’s talk about what is duplicated today, section by section, in the context of HTTP Push since that’s what I’m more familiar with:

1. Introduction and Overview:
* The definitions section can be cut down to just the first sentence stating that the document uses terms defined in RFC8417.
* The remaining text is either boilerplate, or text that is likely to be similar across any specs covering SET distribution.

2. SET Event Stream Protocol
* 2.1 is almost entirely duplicated and can be completely removed.
  - Possible exception around retention of acknowledged SETs, but I’m not convinced this should be normative.
* 2.2 is the core protocol definition and is effectively unique.
* 2.3 describes error reporting. I agree with Mike that we shouldn’t be duplicating SET error codes, and a registry should be defined. Further, I think these error codes are applicable beyond just HTTP Push and Poll.

3. AuthN and AuthZ
* This is a lot of “for example” and “SHOULD” and “MAY”. I think it can be cut down to just the first sentence that states the spec depends on “TLS and/or standard HTTP authentication and authorization schemes as per RFC7235.”

4. Security Considerations
* 4.1 says implementers should sign their SETs if they aren’t using a secure transport. This advice applies to any SET distribution method.
* The rest of this section can be struck, possibly to be replaced with references to appropriate BCPs.

5. Privacy Considerations
* Everything in this section applies to SETs in general, and therefore does not belong in a distribution method spec.

6. IANA Considerations
* There are no IANA considerations.

7. References
* Yup, lots of duplication here. :)

Sent from my iPad

On Jul 19, 2018, at 1:39 AM, Adam Dawes <adawes=[email-masked]<mailto:adawes=[email-masked]>> wrote:

On Wed, Jul 18, 2018 at 4:18 PM Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>> wrote:
The solution to the worry that people would have to implement both is to explicitly say in the single draft that a conforming implementation can implement pull, poll, or both.  I doesn’t have to be any harder than that.

I believe one of the other reasons for separating out the drafts now was that the push spec was more mature and there was high demand for it with RISC. Would it be reasonable to have one spec with three sections and when two of the three sections have WG consensus we cut a draft of it for ratification and then a branch of it with the third sections continues and then when consensus of that is reached we seek ratification on the full version?

From: Id-event <[email-masked]<mailto:[email-masked]>> On Behalf Of Dick Hardt

                                                       -- Mike

•        572 of these lines are identical
•        81% identical for push, 58% identical for poll
•        Move to three delivery specs
•        One for common pieces
•        One for only push-specific pieces
•        One for only poll-specific pieces

--
Adam Dawes | Sr. Product Manager | [email-masked]<mailto:[email-masked]> | +1 650-214-2410

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jul 2018 16:36:14 -0400

In case there is any confusion, duplicating content is problematic in
managing changes.

It appears that the next step in honing the two docs had not occurred.

On Thu, Jul 19, 2018 at 11:02 AM, Richard Backman, Annabelle <
[email-masked]> wrote:

> To some extent that duplication is deliberate. The HTTP Push draft was
> created by starting from the combined draft and stripping out all
> references to HTTP Poll, and vice-versa for the HTTP Poll draft. This was
> done to minimize the risk of introducing unintentional normative changes
> when splitting the draft. I’d originally intended these -00 drafts to live
> just long enough for the WG to confirm that they correctly reflect the
> normative content of the original, at which point we could follow with
> revisions to strip out unnecessary content (which I think there is much
> of). Unfortunately I didn’t drive that process, so we’re still sitting at
> step 0.
>
> With that in mind, let’s talk about what is duplicated today, section by
> section, in the context of HTTP Push since that’s what I’m more familiar
> with:
>
> * The definitions section can be cut down to just the first sentence
> stating that the document uses terms defined in RFC8417.
> * The remaining text is either boilerplate, or text that is likely to be
> similar across any specs covering SET distribution.
>
> * 2.3 describes error reporting. I agree with Mike that we shouldn’t be
> duplicating SET error codes, and a registry should be defined. Further, I
> think these error codes are applicable beyond just HTTP Push and Poll.
>
> 3. AuthN and AuthZ
> * This is a lot of “for example” and “SHOULD” and “MAY”. I think it can be
> cut down to just the first sentence that states the spec depends on “TLS
> and/or standard HTTP authentication and authorization schemes as per
> RFC7235.”
>
> * 4.1 says implementers should sign their SETs if they aren’t using a
> secure transport. This advice applies to any SET distribution method.
> * Everything in this section applies to SETs in general, and therefore
> does not belong in a distribution method spec.
>
> 6. IANA Considerations
> On Jul 19, 2018, at 1:39 AM, Adam Dawes <adawes=40google.com@dmarc.
> ietf.org> wrote:
>
>
> On Wed, Jul 18, 2018 at 4:18 PM Mike Jones <Michael.Jones=40microsoft.
> [email-masked]> wrote:
>
>> There is also the choice of 2 documents. If one of the docs is required
>> to be implemented, then the content could be in that spec, and the other
>> spec could refer to that content.
>>
>>
>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Jul 2018 21:07:42 +0000

Thanks, Dick.  I wanted to add one other point to the list that you and I discussed in person.

There’s lots of precedents in RFCs for implementations being able to conform by implementing one or more options in the spec.  For instance, in the core OAuth spec [RFC 6749], one can conform by implementing either the code flow or the implicit flow.  In the OAuth Bearer spec, one can conform by either sending access tokens using an Authorization header or in the request body.

Thus, there should be no problem in having a single delivery spec that one can conform to by implementing either a push or poll method.  This point apparently wasn’t well known to working group members when the decision was made to split the spec into two.

                                                       -- Mike

From: Dick Hardt <[email-masked]>
Sent: Thursday, July 19, 2018 4:36 PM
To: Richard Backman, Annabelle <[email-masked]>
Cc: Adam Dawes <[email-masked]>; Mike Jones <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Issue Shared by Poll and Push Specs: Massive Duplication

In case there is any confusion, duplicating content is problematic in managing changes.

On Thu, Jul 19, 2018 at 11:02 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
To some extent that duplication is deliberate. The HTTP Push draft was created by starting from the combined draft and stripping out all references to HTTP Poll, and vice-versa for the HTTP Poll draft. This was done to minimize the risk of introducing unintentional normative changes when splitting the draft. I’d originally intended these -00 drafts to live just long enough for the WG to confirm that they correctly reflect the normative content of the original, at which point we could follow with revisions to strip out unnecessary content (which I think there is much of). Unfortunately I didn’t drive that process, so we’re still sitting at step 0.

3. AuthN and AuthZ

6. IANA Considerations

7. References

Sent from my iPad

                                                       -- Mike

---

From: William Denniss <[email-masked]>
Date: Thu, 19 Jul 2018 16:15:22 -0700

I made a similar point at IETF 101 using the code flow / implicit flow
analogy (recording, 19m8s in <https://youtu.be/r0hbpQqsN6s?t=19m8s>). Sometimes
there are simply two valid ways to do something each with their own
separate use-cases, just as code flow and implicit were designed for
different use-cases. We have half the working group saying they want pull,
and half wanting push, both with seemingly valid reasons that preclude
using the other, which points to this being one such case for documenting
two alternatives.

It was the requirement on the group that one method be made MTI that ended
up splitting the document (since neither option really fit the model for
being MTI due to opposing use-cases). If the underlying requirement that
one be made MTI goes away, then so would at least one reason to split the
doc.

Best,
William

On Thu, Jul 19, 2018 at 2:07 PM, Mike Jones <
Michael.Jones=[email-masked]> wrote:

> There’s lots of precedents in RFCs for implementations being able to
> conform by implementing one or more options in the spec.  For instance, in
> the core OAuth spec [RFC 6749], one can conform by implementing either the
> code flow or the implicit flow.  In the OAuth Bearer spec, one can conform
> by either sending access tokens using an Authorization header or in the
> request body.
>
>
>
> Thus, there should be no problem in having a single delivery spec that one
> can conform to by implementing either a push or poll method.  This point
> apparently wasn’t well known to working group members when the decision was
> made to split the spec into two.
>
>
>
>                                                        -- Mike
>
>
>
> *Sent:* Thursday, July 19, 2018 4:36 PM
> *To:* Richard Backman, Annabelle <[email-masked]>
> *Cc:* Adam Dawes <[email-masked]>; Mike Jones <
> [email-masked]>; ID Events Mailing List <[email-masked]>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 19 Jul 2018 19:52:56 -0400

The working group decided in London that neither of the Delivery methods 
is MTI. People can implement either one or both, and still be compliant.

However I think that the other reason to keep the drafts separate is 
still valid: one method is much more mature than the other.

Thanks,
	Yaron

On 19/07/18 19:15, William Denniss wrote:
> analogy (recording, 19m8s in <https://youtu.be/r0hbpQqsN6s?t=19m8s>). 
> Sometimes there are simply two valid ways to do something each with 
> their own separate use-cases, just as code flow and implicit were 
> designed for different use-cases. We have half the working group saying 
> they want pull, and half wanting push, both with seemingly valid reasons 
> that preclude using the other, which points to this being one such case 
> for documenting two alternatives.
> 
> It was the requirement on the group that one method be made MTI that 
> ended up splitting the document (since neither option really fit the 
> model for being MTI due to opposing use-cases). If the underlying 
> requirement that one be made MTI goes away, then so would at least one 
> reason to split the doc.
> 
> Best,
> William
> 
> 
> 
> On Thu, Jul 19, 2018 at 2:07 PM, Mike Jones 
> <Michael.Jones=[email-masked] 
> <mailto:Michael.Jones=[email-masked]>> wrote:
> 
>     Thanks, Dick.  I wanted to add one other point to the list that you
>     and I discussed in person.____
> 
>     __ __
> 
>     conform by implementing one or more options in the spec.  For
>     instance, in the core OAuth spec [RFC 6749], one can conform by
>     implementing either the code flow or the implicit flow.  In the
>     OAuth Bearer spec, one can conform by either sending access tokens
>     using an Authorization header or in the request body.____
> 
>     __ __
> 
>     Thus, there should be no problem in having a single delivery spec
>     that one can conform to by implementing either a push or poll
>     method.  This point apparently wasn’t well known to working group
>     members when the decision was made to split the spec into two.____
> 
>     __ __
> 
>                               -- Mike____
> 
>     __ __
> 
>     *From:* Dick Hardt <[email-masked] <mailto:[email-masked]>>
>     *To:* Richard Backman, Annabelle <[email-masked]
>     <mailto:richanna@amazon..com>>
>     *Cc:* Adam Dawes <[email-masked] <mailto:[email-masked]>>;
>     Mike Jones <[email-masked]
>     <mailto:[email-masked]>>; ID Events Mailing List
>     <[email-masked] <mailto:[email-masked]>>
> 
> 
>     *Subject:* Re: [Id-event] Issue Shared by Poll and Push Specs:
>     Massive Duplication____
> 
>     __ __
> 
>     In case there is any confusion, duplicating content is problematic
>     in managing changes. ____
> 
>     __ __
> 
>     It appears that the next step in honing the two docs had not
>     occurred. ____
> 
>     __ __
> 
>     On Thu, Jul 19, 2018 at 11:02 AM, Richard Backman, Annabelle
>     <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         To some extent that duplication is deliberate. The HTTP Push
>         draft was created by starting from the combined draft and
>         stripping out all references to HTTP Poll, and vice-versa for
>         the HTTP Poll draft. This was done to minimize the risk of
>         introducing unintentional normative changes when splitting the
>         draft. I’d originally intended these -00 drafts to live just
>         long enough for the WG to confirm that they correctly reflect
>         the normative content of the original, at which point we could
>         follow with revisions to strip out unnecessary content (which I
>         think there is much of). Unfortunately I didn’t drive that
>         process, so we’re still sitting at step 0. ____
> 
>         __ __
> 
>         With that in mind, let’s talk about what is duplicated today,
>         section by section, in the context of HTTP Push since that’s
>         what I’m more familiar with:____
> 
>         __ __
> 
>         1. Introduction and Overview:____
> 
>         * The definitions section can be cut down to just the first
>         sentence stating that the document uses terms defined in
>         RFC8417.____
> 
>         * The remaining text is either boilerplate, or text that is
>         likely to be similar across any specs covering SET distribution.____
> 
>         __ __
> 
>         2. SET Event Stream Protocol____
> 
>         * 2.1 is almost entirely duplicated and can be completely
>         removed.____
> 
>            - Possible exception around retention of acknowledged SETs,
>         but I’m not convinced this should be normative.____
> 
>         * 2.2 is the core protocol definition and is effectively unique.____
> 
>         * 2.3 describes error reporting. I agree with Mike that we
>         shouldn’t be duplicating SET error codes, and a registry should
>         be defined. Further, I think these error codes are applicable
>         beyond just HTTP Push and Poll.____
> 
>         __ __
> 
>         3. AuthN and AuthZ____
> 
>         * This is a lot of “for example” and “SHOULD” and “MAY”. I think
>         it can be cut down to just the first sentence that states the
>         spec depends on “TLS and/or standard HTTP authentication and
>         authorization schemes as per RFC7235.”____
> 
>         __ __
> 
>         4. Security Considerations____
> 
>         * 4.1 says implementers should sign their SETs if they aren’t
>         using a secure transport. This advice applies to any SET
>         distribution method.____
> 
>         * The rest of this section can be struck, possibly to be
>         replaced with references to appropriate BCPs.____
> 
>         __ __
> 
>         5. Privacy Considerations____
> 
>         * Everything in this section applies to SETs in general, and
>         therefore does not belong in a distribution method spec.____
> 
>         __ __
> 
>         6. IANA Considerations____
> 
>         * There are no IANA considerations.____
> 
>         __ __
> 
>         7. References____
> 
>         * Yup, lots of duplication here. :)____
> 
>         __ __
> 
>         Sent from my iPad____
> 
> 
>         On Jul 19, 2018, at 1:39 AM, Adam Dawes
>         <adawes=[email-masked]
>         <mailto:adawes=[email-masked]>> wrote:____
> 
>             __ __
> 
>             On Wed, Jul 18, 2018 at 4:18 PM Mike Jones
>             <Michael.Jones=[email-masked]
>             <mailto:[email-masked]>> wrote:____
> 
>                 The solution to the worry that people would have to
>                 implement both is to explicitly say in the single draft
>                 that a conforming implementation can implement pull,
>                 poll, or both.  I doesn’t have to be any harder than
>                 that.____
> 
>             __ __
> 
>             I believe one of the other reasons for separating out the
>             drafts now was that the push spec was more mature and there
>             was high demand for it with RISC. Would it be reasonable to
>             have one spec with three sections and when two of the three
>             sections have WG consensus we cut a draft of it for
>             ratification and then a branch of it with the third sections
>             continues and then when consensus of that is reached we seek
>             ratification on the full version?____
> 
>             __ __
> 
>             __ __
> 
>             __ __
> 
>             __ __
> 
>             ____
> 
>                 *From:* Id-event <[email-masked]
>                 <mailto:[email-masked]>> *On Behalf Of *Dick
>                 Hardt
>                 *To:* Mike Jones <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc:* [email-masked] <mailto:[email-masked]>
>                 *Subject:* Re: [Id-event] Issue Shared by Poll and Push
>                 Specs: Massive Duplication____
> 
>                 ____
> 
>                 There is an acronym I am forgetting that said about what
>                 was minimally required to implement to be compliant. I
>                 am likely using the wrong words. There was concern from
>                 implementors that they would have to implement both
>                 "push" and "poll" if both are in the same document, and
>                 many implementors only expected to implement one method.
>                 ____
> 
>                 ____
> 
>                 *if* one is only implementing one, then two docs are
>                 better than one, as you only have to read what you are
>                 implementing.____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 On Wed, Jul 18, 2018 at 6:06 PM, Mike Jones
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:____
> 
>                     We can’t require that everyone implement an RFC. 
>                     Whether to do so is always a choice.____
> 
>                     ____
> 
>                     In the two RFCs case, even though neither would be
>                     required, one could contain all the common content
>                     and the other reference it.  Some of that was done
>                     between JWS [RFC 7515] and JWE [RFC 7516], for
>                     example, to remove duplication that had been present
>                     at one point.____
> 
>                     ____
> 
>                     I agree with you that having to read a large set of
>                     documents is suboptimal.  As I see it, one would be
>                     better than two, which would be better than three.____
> 
>                     ____
> 
>                                               -- Mike____
> 
>                     ____
> 
>                     *From:* Dick Hardt <[email-masked]
>                     <mailto:[email-masked]>>
>                     *To:* Mike Jones <[email-masked]
>                     <mailto:[email-masked]>>
>                     *Cc:* [email-masked] <mailto:[email-masked]>
>                     *Subject:* Re: [Id-event] Issue Shared by Poll and
>                     Push Specs: Massive Duplication____
> 
>                     ____
> 
>                     There is also the choice of 2 documents. If one of
>                     the docs is required to be implemented, then the
>                     content could be in that spec, and the other spec
>                     could refer to that content. ____
> 
>                     ____
> 
>                     Personally, I hate having to read a large set of
>                     different documents to figure out how to do
>                     something.____
> 
>                     ____
> 
>                     ____
> 
>                     On Wed, Jul 18, 2018 at 5:53 PM, Mike Jones
>                     <Michael.Jones=40microsoft.com@dmarc..ietf.org
>                     <mailto:Michael.Jones=[email-masked]>>
>                     wrote:____
> 
>                         *Massive Duplication Across Poll and Push Specs*____
> 
>                           * Content of 6 of 7 top-level sections in both
>                             specs duplicated____
>                           * Push source is 708 lines, poll is 984 lines ____
> 
>                         ·572 of these lines are identical____
> 
>                         ·81% identical for push, 58% identical for poll____
> 
>                         *Problems with Duplication*____
> 
>                         ·Not perfectly duplicated ____
> 
>                         ·Edits to common text have already been
>                         inconsistently applied in several cases____
> 
>                         ·Requires manual editor actions to keep in sync____
> 
>                         ·Sometimes unclear which divergences intentional____
> 
>                         ·Some normative data structures duplicated ____
> 
>                         ·For instance, error values defined twice____
> 
>                         ·Will they be kept in sync?____
> 
>                         ·Will they live in a common registry?____
> 
>                         ·Which will be authoritative?____
> 
>                         *Assertion: Current Organization Untenable*____
> 
>                         ·Massive duplication creates consistency
>                         nightmare for editors ____
> 
>                         ·Manual steps to keep common text consistent____
> 
>                         ·Massive duplication creates significant work
>                         for reviewers ____
> 
>                         ·Having to figure out what’s the same and what’s
>                         different and try to understand why____
> 
>                         ·Massive duplication will confuse implementers ____
> 
>                         ·Having to figure out what’s the same and what’s
>                         different and try to understand why____
> 
>                         *Possible Solutions*____
> 
>                         ·Move to three delivery specs ____
> 
>                         ·One for common pieces____
> 
>                         ·One for only push-specific pieces____
> 
>                         ·One for only poll-specific pieces____
> 
>                         ·Move to one delivery spec ____
> 
>                         ·All text occurs only once____
> 
>                         ·Push-specific pieces in one section____
> 
>                         ·Poll-specific pieces in a different section____
> 
>                         ·Note: Both mechanisms could still be optional____
> 
>                         ·/I believe this will be easier for all to
>                         understand/____
> 
>                         *Discussion*____
> 
>                         ·As an editor, I’m not prone to fix problems in
>                         duplicated text until we solve the duplication
>                         problem ____
> 
>                         ·Unreasonable to ask us to do everything twice____
> 
>                         ·Data gathering ____
> 
>                         ·Who has reviewed both specs?____
> 
>                         ·What was your experience reviewing them?____
> 
>                         ·How should we solve the duplication problem? ____
> 
>                         ·Should we have one or three specs?____
> 
>                         ____
> 
> 
>                         [email-masked] <mailto:[email-masked]>
>                         <https://www.ietf.org/mailman/listinfo/id-event>____
> 
>                     ____
> 
>                 ____
> 
>                 [email-masked] <mailto:[email-masked]>
>                 <https://www.ietf.org/mailman/listinfo/id-event>____
> 
> 
>             ____
> 
>             __ __
> 
>             -- ____
> 
>             Adam Dawes | Sr. Product Manager [email-masked]
>             <mailto:[email-masked]> |+1 650-214-2410____
> 
>             __ __
> 
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/id-event>____
> 
>     __ __
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/id-event>
> 
> 
> 
>