Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Jan 2012 20:54:11 +0000

On 09/12/2011 17:19, Alexey Melnikov wrote:
> Dear WG participant,
> I would like to initiate WGLC on draft-ietf-appsawg-xdash-02.txt. Due 
> to holiday season the WGLC is going to be a long one and will end on 
> January 6th. Please send any comments directly to the apps-discuss 
> mailing list, or directly to editors of the draft and myself.
> Please send an email even if you reviewed the document and found no 
> issues with it.
>
> Thank you,
> Alexey, as an APPSAWG co-chair.
Truly yours was quite disorganized and the WGLC is definitely over by 
now. However there weren't many comments on the document, so it is 
either perfect or people don't care. I would like to give people a 
couple of extra days (till the end of Sunday) to contemplate errors of 
their ways (and redeem themselves by late reviews), at which point I am 
likely to do the shepherding write-up and ask our AD Pete to sponsor 
publication of the document.

Best Regards,
Alexey, as an APPSAWG co-chair.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jan 2012 15:03:14 -0800

On Jan 24, 2012, at 12:54 PM, Alexey Melnikov wrote:

> However there weren't many comments on the document, so it is either perfect or people don't care.

That's somewhat disingenuous. Some of us care very much but didn't think that commenting on the document would have any effect on the outcome.

My comments: the document makes grandiose, over-arching suggestions that indicate a one-size-fits-all view of the standards process. I would probably do the same if I were co-author of this document, with half of my suggestions being the same as what is the draft and half being the opposite.

A different way to do the document would be a single paragraph: "People have thought about this topic for over a decade, probably much harder than you are thinking about this now. They often disagreed with each other, indicating that you are not thinking hard enough about your current choices. Whatever you choose to do with respect to not-yet-defined parameters, you will likely regret the choice if your protocol is at all popular." Such a concise document is much easier to read and much less likely to be noticed than the current one.

--Paul Hoffman

---

From: SM <[email-masked]>
Date: Tue, 24 Jan 2012 19:17:39 -0800

Hi Paul,
At 15:03 24-01-2012, Paul Hoffman wrote:
>A different way to do the document would be a single paragraph: 
>"People have thought about this topic for over a decade, probably 
>much harder than you are thinking about this now. They often 
>disagreed with each other, indicating that you are not thinking hard 
>enough about your current choices. Whatever you choose to do with 
>respect to not-yet-defined parameters, you will likely regret the 
>choice if your protocol is at all popular." Such a concise document 
>is much easier to read and much less likely to be noticed than the current one.

The above express the idea in simple words.  There aren't any RFC 
2119 key words though.  That's highly inappropriate for a BCP. :-)

I suggest moving draft-ietf-appsawg-xdash-02 to Last Call it is 
written in a language which protocol designers ought to understand.

Regards,
-sm

---

From: "t.petch" <[email-masked]>
Date: Wed, 25 Jan 2012 10:24:01 +0100

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 25, 2012 12:03 AM

> That's somewhat disingenuous. Some of us care very much but didn't think that
commenting on the document would have any effect on the outcome.

Yes, my thoughts exactly.  The document reads like an edict from a socialist
state, 'in future, you will ...[insert nonsense appropriate to your culture]'
and taking on socialist states is a losing game for the individual.

But you ask.  The body of the document is dogmatic, the support for the bald
statement lies in Appendix B (normative?) and is almost as weak.  The e-mail
that came to me contained 15 distinct X- headers; what are the creators of those
meant to do now?  And what in future when they wish to develop or experiment
with a new idea, perhaps one that will be very successful but only within a
walled garden?

The real failure lies with SMTP, MIME etc, or those who specified it, who failed
to see the need for migration (all too common a point of view in the IETF).
Having a private namespace in which to develop and experiment without harming
the Internet is an excellent idea and crops up in many forms, of which this I-D
only addresses the 'X-' format.  When such work is successful, and the desire is
there to move it to the Internet, then a migration strategy is needed and it is
this that the MIMiEs etc failed to plan for.  This failure does not invalidate
the case for a private portion of the namespace.

And, to be expected really, this I-D fails to consider migration; what is going
to happen now to those 15 X- headers and all the others that are in other
e-mails?  Where is your migration plan?

And what about all the other private portions of namespaces that are designated
with something other than X-?  Will you produce an edict prohibiting them as
well?

Tom Petch

> My comments: the document makes grandiose, over-arching suggestions that
indicate a one-size-fits-all view of the standards process. I would probably do
the same if I were co-author of this document, with half of my suggestions being
the same as what is the draft and half being the opposite.
>
> A different way to do the document would be a single paragraph: "People have
thought about this topic for over a decade, probably much harder than you are
thinking about this now. They often disagreed with each other, indicating that
you are not thinking hard enough about your current choices. Whatever you choose
to do with respect to not-yet-defined parameters, you will likely regret the
choice if your protocol is at all popular." Such a concise document is much
easier to read and much less likely to be noticed than the current one.
>
> --Paul Hoffman
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 11:43:02 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Wednesday, January 25, 2012 1:24 AM
> To: Paul Hoffman; Alexey Melnikov
> Cc: [email-masked]
> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt
> 
> And, to be expected really, this I-D fails to consider migration; what
> is going to happen now to those 15 X- headers and all the others that
> are in other e-mails?  Where is your migration plan?

I think it's there in plain sight: Drop the "X-" and register them.

I think it's also clear that this can't affect deployed software that actually looks for "X-" fields, but rather encourages new implementations of things to avoid this practice.  Seems perfectly reasonable to me.

If the document doesn't already say something like that, I agree that it would be a useful thing to say.

> And what about all the other private portions of namespaces that are
> designated with something other than X-?  Will you produce an edict
> prohibiting them as well?

The abstract says that this "causes more problems than it solves."  Do you envision some other solution to those problems?

-MSK

---

From: SM <[email-masked]>
Date: Wed, 25 Jan 2012 12:06:46 -0800

Hi Murray,
>I think it's there in plain sight: Drop the "X-" and register them.

https://sites.google.com/site/oauthgoog/mlistsdkim

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 12:12:00 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Wednesday, January 25, 2012 12:07 PM
> To: [email-masked]
> Subject: [apps-discuss] X-Original (was: WGLC on draft-ietf-appsawg-xdash-02.txt)
> 
> Hi Murray,

I'm working with them on that, actually.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Jan 2012 13:28:25 -0700

On 1/25/12 12:43 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of t.petch Sent:
>> Wednesday, January 25, 2012 1:24 AM To: Paul Hoffman; Alexey
>> Melnikov Cc: [email-masked] Subject: Re: [apps-discuss] WGLC
>> on draft-ietf-appsawg-xdash-02.txt
>> 
>> And, to be expected really, this I-D fails to consider migration;
>> what is going to happen now to those 15 X- headers and all the
>> others that are in other e-mails?  Where is your migration plan?
> 

Why drop the "X-" on existing parameters? Yes, that wasn't such a great
idea, but the parameters exist, so there's no need to change them.
Please note what Section 6 ("IANA Considerations") states:

   This document does not modify registration procedures currently in
   force for various application protocols.  However, such procedures
   might be updated in the future to incorporate the best practices
   defined in this document.

> I think it's also clear that this can't affect deployed software that
> actually looks for "X-" fields, but rather encourages new
> implementations of things to avoid this practice.  Seems perfectly
> reasonable to me.

Yes, and the recommendations for creators of new parameters (Section 3)
and for protocol designers (Section 4) are intentionally worded in terms
of new parameters and protocols, not existing ones.

> it would be a useful thing to say.

It already does.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 12:33:22 -0800

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Wednesday, January 25, 2012 12:28 PM
> To: Murray S. Kucherawy

I guess I'm thinking of those applications that produce X- fields where nothing (apparently) consumes them in an automated way.  In those cases, renaming and registering is harmless.

Those that do need a transition plan, which is typically "accept/expect either form" in my experience.

---

From: Zoltan Ordogh <[email-masked]>
Date: Thu, 26 Jan 2012 14:58:23 +0000

Looks "perfect" to me; I have only one question on section 3, bullet 2:
How would you know that a name is unused?

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey
> Melnikov
> Sent: January 24, 2012 3:54 PM
> Truly yours was quite disorganized and the WGLC is definitely over by now. However there weren't many
> comments on the document, so it is either perfect or people don't care. I would like to give people a
> couple of extra days (till the end of Sunday) to contemplate errors of their ways (and redeem
> themselves by late reviews), at which point I am likely to do the shepherding write-up and ask our AD
> Pete to sponsor publication of the document.
> 
> Best Regards,

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 09:11:27 -0700

> How would you know that a name is unused?

How about this?

"SHOULD employ meaningful names that they have reason to believe are
currently unused"

You can't prove a negative, so that text is more actionable (e.g., you
could do a quick Internet search to avoid obvious overlaps).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Zoltan Ordogh <[email-masked]>
Date: Thu, 26 Jan 2012 17:16:36 +0000

Hi Peter,
I think that it is better. Frankly, I am not sure what would be a fool-proof solution to this.
I do realize however, it has little to do with the X- being there or missing...

PS. Internet searches are not only unreliable, but also tied to a certain "snapshot" of the internet taken at a specific point in time.

> Sent: January 26, 2012 11:11 AM
> To: Zoltan Ordogh
> Cc: Alexey Melnikov; [email-masked]
> "SHOULD employ meaningful names that they have reason to believe are currently unused"
> 
> You can't prove a negative, so that text is more actionable (e.g., you could do a quick Internet
> search to avoid obvious overlaps).
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 10:19:42 -0700

On 1/26/12 10:16 AM, Zoltan Ordogh wrote:
> Hi Peter, I think that it is better. Frankly, I am not sure what
> would be a fool-proof solution to this. 

I'm not fool enough to seek fool-proof solutions.

> I do realize however, it has
> little to do with the X- being there or missing...
> 
> PS. Internet searches are not only unreliable, but also tied to a
> certain "snapshot" of the internet taken at a specific point in
> time.

Thus the word "currently". :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "t.petch" <[email-masked]>
Date: Fri, 27 Jan 2012 17:08:48 +0100

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 25, 2012 8:43 PM
> I think it's also clear that this can't affect deployed software that actually
looks for "X-" fields, but rather encourages new implementations of things to
avoid this practice.  Seems perfectly reasonable to me.
> If the document doesn't already say something like that, I agree that it would
be a useful thing to say.

I do not see it in the I-D, about what, if anything, this I-D expects to change
with the parameters currently in use.  The sort of parameters I have in mind are
those that appear in the header of the e-mail you originated, such as

As far as I know, none of them make any difference to what I experience as a
mail user and I would be just as happy if a passing MTA stripped them all out -
which with X- it might consider doing, whereas without, it could not take the
risk.  In fact, I would love to see them stripped out, reducing the amount of
data I download and store:-)

Tom Petch

> The abstract says that this "causes more problems than it solves."  Do you
envision some other solution to those problems?

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Jan 2012 09:33:08 -0800

On 1/27/2012 8:08 AM, t.petch wrote:
> with the parameters currently in use.

If you think that's a problem, please explain why and offer some text to cover it.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Jan 2012 09:43:59 -0800

> From: t.petch [mailto:[email-masked]]
> Sent: Friday, January 27, 2012 8:09 AM
> To: Murray S. Kucherawy; [email-masked]
> I do not see it in the I-D, about what, if anything, this I-D expects
> to change with the parameters currently in use.  The sort of parameters
> I have in mind are those that appear in the header of the e-mail you
> originated, such as
> [...]

I think Peter responded to this point a couple of days ago.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jan 2012 10:13:32 -0800

After discussing this a bit more with Pete Resnick off-line, we found a place where I missed a major assumption: this draft is only about parameter names, not numbers. Pete believes that this changes things hugely, but I am less sure. Regardless, we agreed it needs to be clarified.

Proposed text to be added after the second paragraph of Section 1:

Note that this document only discusses parameters with text names; it does not discuss parameters that are expressed with numbers. The difference between these two is that text names of parameters (for example, "hash-type" and "x-hash-type") tend to appear in administrative and user interfaces much more often than numbers that identify parameters (for example, 7 or 0xa007). The misuse of parameters with text names and with numbers are similar; developers will try to get experimental parameters standardized without changing the parameter value, developers mis-use unassigned values without going through the defined registration procedure, and so on. However, the more likely exposure to administrators and users limits the focus of this document only to named parameters.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 11:34:34 -0700

On 1/27/12 11:13 AM, Paul Hoffman wrote:
> After discussing this a bit more with Pete Resnick off-line, we found
> a place where I missed a major assumption: this draft is only about
> parameter names, not numbers. Pete believes that this changes things
> hugely, but I am less sure. Regardless, we agreed it needs to be
> clarified.

That's been implicit in the document, but I agree that we need to make
it explicit.

> Note that this document only discusses parameters with text names; it
> does not discuss parameters that are expressed with numbers. The
> difference between these two is that text names of parameters (for
> example, "hash-type" and "x-hash-type") tend to appear in
> administrative and user interfaces much more often than numbers that
> identify parameters (for example, 7 or 0xa007). The misuse of
> parameters with text names and with numbers are similar; developers
> will try to get experimental parameters standardized without changing
> the parameter value, developers mis-use unassigned values without
> going through the defined registration procedure, and so on. However,
> the more likely exposure to administrators and users limits the focus
> of this document only to named parameters.

Proposed text is always appreciated. :)

It's not clear to me what function the third sentence serves; we don't
talk elsewhere about the misuse of parameters. With some editing, I suggest:

Because textual names of parameters (e.g., "hash-type" and
"x-hash-type") tend to appear in administrative and user interfaces much
more often than numbers that identify parameters (e.g., 7 or 0xa007),
this document discusses only parameters with textual names, not
parameters that are expressed with numbers.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Jan 2012 10:40:11 -0800

On 1/27/2012 10:34 AM, Peter Saint-Andre wrote:
> Proposed text is always appreciated.:)
>

In fact I'm unclear about what problem the added text solves.  It seems to focus 
on issues that are out of scope for the draft.

At best, an aid to the reader to understand that scope seems sufficient, along 
the lines of Paul's prefatory sentence:

      The specification only cover parameter names, not numbers.

d/

-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 11:41:19 -0700

On 1/27/12 11:40 AM, Dave CROCKER wrote:
> In fact I'm unclear about what problem the added text solves.  It seems
> to focus on issues that are out of scope for the draft.
> 
> At best, an aid to the reader to understand that scope seems sufficient,
> along the lines of Paul's prefatory sentence:
> 

Brevity is good.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 11:44:29 -0700

>>      The specification only cover parameter names, not numbers.

I suggest slightly modifying the second paragraph of the introduction:

   Although in theory the "X-" convention was a good way to avoid
   collisions (and attendant interoperability problems) between
   standard parameters and non-standard parameters, in practice the
   benefits have been outweighed by the costs associated with the
   leakage of non-standard parameters into the standards space.
   Therefore this document deprecates the "X-" convention for named
   parameters in application protocols and makes specific
   recommendations about how to proceed in a world without the
   distinction between standard and non-standard parameters.  Note that
   this document covers named parameters only, not numbers.

/psa

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jan 2012 10:47:27 -0800

>>     The specification only cover parameter names, not numbers.

...except when it excludes the reasoning for the text.

As you say before, the document doesn't directly address the misuse of parameters, although it hints at it. If you think only hinting is useful (I don't), then not even hinting at why the document only covers names is probably fine.

I really think you are undershooting here.

--Paul Hoffman

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Jan 2012 11:02:37 -0800

> ...except when it excludes the reasoning for the text.

This appears to be a different concern than the one you've offered text for.
What 'reasoning' is missing and what text do you suggest for remedying it?

> As you say before, the document doesn't directly address the misuse of
> parameters, although it hints at it. If you think only hinting is useful (I
> don't), then not even hinting at why the document only covers names is
> probably fine.

Whereas I believe this document has nothing at all to do with "abuse" or
"misuse" and doesn't hint or pretend otherwise.

It has to do with a well-intentioned convention that has been used reasonably
but has proved counter-productive.

> I really think you are undershooting here.

And since I think your are significantly overshooting, do we cancel each other out?

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Jan 2012 11:48:47 -0800

>>       The specification only cover parameter names, not numbers.

Usually.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Jan 2012 13:04:22 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Friday, January 27, 2012 11:49 AM
> To: Peter Saint-Andre
> Cc: Paul Hoffman; [email-masked]

+1

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Jan 2012 13:30:42 -0800

>> Usually.

!

d/

ps.  full disclosure: that was murray's idea.

-- 

   Dave Crocker