Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.txt

Some nits on this sentence:

   For a web browser (HTTP User Agent), the contents of the ORIGIN
   attribute is the unicode-serialization of an origin defined in
   Section 6.1 of [RFC6454].

I think that using "for a web browser" here is redundant, since the
entire point of the document is that web browsers are the ones adding
this (other users are going to add whatever gets them what they want).

The second is that it's the UTF-8 encoding of the unicode-serialization.

And this sentence:

   [...]  It MUST contain a
   UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes.
   The value of 268 is chosen to be larger than the maximum 253
   character domain name plus 8 characters for the URI scheme plus 5
   characters for the port number.

This arbitrary restriction doesn't seem like a great idea.  If the
coding efficiency of UTF-8 is strictly better than punycode, then it's
probably OK, but why be so strict?  Is there a strict need to limit
this to URIs with 5-character-or-less schemes?

On 28 June 2014 10:04, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> All,
>
> We have updated the STUN Origin draft.  The major changes relate to:
>
> 1. Adding sections on media keep-alive and SIP keep-alive usages
> 2. Adding a section on multiple origins
> 3. Adding a section on Implementation Status about the open source
> implementations of the browser and STUN/TURN server that support the ORIGIN
> attribute
> 4. Clarified integrity protection of the attribute in the Security
> Considerations section.
>
> These changes are based on all recent reviews and mailing list comments.
>
> As always, comments are most welcome!
>
> - Alan -
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Sat, Jun 28, 2014 at 11:50 AM
> Subject: New Version Notification for draft-johnston-tram-stun-origin-03.txt
> To: Kundan Singh <kundan10@gmail.com>, Alan Johnston
> <alan.b.johnston@gmail.com>, John Yoakum <yoakum@avaya.com>, Justin Uberti
> <justin@uberti.name>
>
>
>
> A new version of I-D, draft-johnston-tram-stun-origin-03.txt
> has been successfully submitted by Alan Johnston and posted to the
> IETF repository.
>
> Name:           draft-johnston-tram-stun-origin
> Revision:       03
> Title:          An Origin Attribute for the STUN Protocol
> Document date:  2014-06-28
> Group:          Individual Submission
> Pages:          13
> URL:
> http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/
> Htmlized:
> http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03
>
> Abstract:
>    STUN, or Session Traversal Utilities for NAT, is a protocol used to
>    assist other protocols traverse Network Address Translators or NATs.
>    STUN, and STUN extensions such as TURN, or Traversal Using Relays
>    around NAT, and ICE, Interactive Communications Establishment, have
>    been around for many years but with WebRTC, Web Real-Time
>    Communications, STUN and related extensions are about to see major
>    deployments and implementation due to these protocols being
>    implemented in browsers.  This specification defines an ORIGIN
>    attribute for STUN that can be used in similar ways to the HTTP
>    header field of the same name.  WebRTC browsers utilizing STUN and
>    TURN would include this attribute which would provide servers with
>    additional information about the STUN and TURN requests they receive.
>    This specification defines the usage of the STUN ORIGIN attribute for
>    web and SIP contexts.
>
>
>
>
> 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
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>