Subject: [apps-discuss] Unified User-Agent String

From: Mateusz Karcz <[email-masked]>
Date: Tue, 10 Jul 2012 16:05:12 +0200

Good afternoon! I'm Mateusz Karcz. I'm author of "Unified User-Agent String (UUAS)" I-D (draft-karcz-uuas-00). I had sent it to RFC Editor as Independent Submission, but after I got suggestion from ISB to publicate it by appsawg, because it extends application layer protocol (HTTP) header. Can I develop that draft with You?
     Sincerelly
     Mateusz Karcz

---

From: Andreas Petersson <[email-masked]>
Date: Wed, 11 Jul 2012 11:44:11 +0200

On Tue, 10 Jul 2012 16:05:12 +0200

> Good afternoon! I'm Mateusz Karcz. I'm author of "Unified User-Agent String (UUAS)" I-D (draft-karcz-uuas-00). I had sent it to RFC Editor as Independent Submission, but after I got suggestion from…

Some quick comments on the draft:

1. Is this supposed to be put as value in the current
   "User-Agent"-header field, or is this a new header field?
   If this is to be put in the "User-Agent"-field, how does
   this relate to Section 10.10 of draft-ietf-httpbis-p2-semantics-19
   or 14.43 of RFC2616?

2. I think the use of sub-sub-sub-sections make the structure a
   bit... strange. :-)

3. What is security level? How is it used? References? Should it be
   possible to extend the values?

4. I think it would be better if you use productions from RFC5234,
   instead of specifying ranges of hexadecimal-values.

   I also believe that you can write:
     uuas = agent [ SP engine ] 
   instead of:
     uuas = agent *1(SP engine)

5. RFC2068 is listed as a normative reference, but it is not mentioned
   in the text. Further, it is obsoleted by RFC2616 since like over ten
   years ago. :-) RFC2616 is also to be obsoleted by httpbis pretty
   soon, I assume.

Best regards,
 Andreas

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jul 2012 12:05:52 +0200

>     this relate to Section 10.10 of draft-ietf-httpbis-p2-semantics-19

Indeed. You can't update the definition of a header field that is 
already widely deployed by something experimental.

Another point:

   Security is truly believed to be irrelevant to this document.

This indicated that you may not have done sufficient research on the use 
of "User-Agent" :-)

Best regards, Julian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Jul 2012 08:09:07 -0700

> already widely deployed by something experimental.

To quote an under-appreciated engineer who was once President of the 
United States:  we could do it, but it would be wrong.

> This indicated that you may not have done sufficient research on the use

Indeed.  Given that web sites often behave very differently for 
different browsers, this would seem to have a great deal of potential 
security effects.

In general, the proposal lacks clear motivation.  As a theoretical 
topic, it seems reasonable to standardize the meta-data describing the 
user agent serving as the client.  However standardization at this stage 
of operational history requires documenting the specific problems or 
other needs that will drive the design.

That is:

1) what existing difficulties in client/server interaction are currently 
related to this string or would be mitigated by standardizing it?

2) what is the evidence that client and server implementers will adopt a 
standard string?

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Wed, 11 Jul 2012 08:19:17 -0700 (PDT)

I'm in agreement with everything Dave says below. That said, a document that
first discusses the issues with this field fully and completely, then justifies
(not standardizes) specification of a new format, and finally proceeds to
define that format, could turn out to be a Good Thing.

FWIW, the way I'd do it is to separate the issue intrinsic to the use of the
field in any way from the issues that arise from inconsistent use of field
values. The former are unresolvable, and may actually be made worse by a
consistent format, but the latter are the thing a consistent format would
address. 

				Ned

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mateusz Karcz <[email-masked]>
Date: Wed, 11 Jul 2012 18:40:07 +0200

So I had to:
1. Add references to HTTP specification.
2. Simply syntax definition.
3. Separate issue definition and actual problems definition.
4. Write Security Considerations.
5. Change form of draft from standarising to proposing.
6. Find examples of errors, which are result of ambiguous strings.
7. Change order of elements in draft.
8. Think two times about sense of that project.

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Jul 2012 18:17:18 -0700 (PDT)

> 8. Think two times about sense of that project.

I'm sorry to have to say it, but this completely misses the main
point of what I was suggesting. My suggestion was to write a document
that was first about the issues in general that arise from use of
the User-Agent string, and only secondarily about how a subset of those
issues can be addresses by nailing down the syntax.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Jul 2012 08:08:53 -0700

On 7/13/2012 6:17 PM, Ned Freed wrote:
> My suggestion was to write a document

+1

d/

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 20 Jul 2012 11:59:23 +0300

> issues can be addresses by nailing down the syntax.

Furthermore, without implementor interest, this isn't going to go
anywhere, and the draft seems completely out of touch with implementor
interest. For example,
http://tools.ietf.org/html/draft-karcz-uuas-00#section-2.1.2.1
describes a legacy thing that no implementor seems to be interested in
adding at this point if they don't already have it, and implementors
who still did have it two years ago have been removing it.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Ned Freed <[email-masked]>
Date: Fri, 20 Jul 2012 08:12:55 -0700 (PDT)

> who still did have it two years ago have been removing it.

Exactly. A document that explains a security issue first and proposes an
implementation strategy second has value even if the second part is ignored.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Jul 2012 10:38:31 +1000

+1

--
Mark Nottingham
http://www.mnot.net/