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

Martin,

Thanks for the feedback on the draft - see my replies below.

- Alan -

On Mon, Jun 30, 2014 at 12:16 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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.
>
>
This paragraph, and the two following it define what this new attribute
carries. (The other two paragraphs begin "For a SIP User Agent..." and "For
a Jabber client...")  How about if I say instead:

"If inserted by a web browser, the ORIGIN attribute contains the UTF-8
encoding of the unicode-serialization of an origin defined in Section 6.1
of [RFC6454]."

> 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?
>
>
>
I agree we don't want to limit it to 5-character-or-less URI schemes.  The
reason this text is there is because of concerns that this attribute will
make STUN messages too big. How much extra space should we allow.  Up to
280 octets?  Or should we just point out that origin strings from RFC6454
are likely to be around 253 octets long, and using strings that are
significantly longer is NOT RECOMMENDED.

>
> 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
> >
>