Subject: [apps-discuss] Review of: draft-ietf-appsawg-media-type-suffix-regs-00

From: Dave Crocker <[email-masked]>
Date: Thu, 17 May 2012 08:49:34 -0700

G'day.

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see

http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document:

    draft-ietf-appsawg-media-type-suffix-regs-00

Title:

    Additional Media Type Structured Syntax Suffixes

Reviewer:

    D. Crocker <[email-masked]>

Review Date:

    17 May 2012

Summary:

    Content media type names often contain an informal meta-syntax for 
distinguishing encoding conventions for the media type.  The current 
document formalizes the convention and registered some existing specific 
uses.  The document is straightforward in organization and writing.  It 
is workable in its current form.  The Detailed Comments, below suggest 
some improvements, but none is essential for publication.

d/

Detailed comments:

> Abstract
>
>    This document defines several Structured Syntax Suffixes for use with
>    media type registrations.  In particular, it defines and registers
>    the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip"
>    Structured Syntax Suffixes, and updates the "+xml" Structured Syntax
>    Suffix registration.

Using a term of art in an abstract -- or anywhere else -- requires that 
readers know its meaning.  Absent very-broad, pre-existing knowledge of 
the term, it should be explained, even in the abstract.  I suggest 
opening with something like:

    A content media types name sometimes includes partitioned 
meta-information distinguish by a Structured Syntax, to permit noting an 
attribute of the media as a suffix to the name.

> 1.  Introduction
>
>    [RFC3023] created the +xml suffix convention that may be used by

    may be used by -> may be used when defining names for

>    media types whose representation uses XML underneath, that is, they

    underneath, that is  ->  underneath. That is

>    could have been successfully parsed as if the media type had been
>    application/xml in addition to their being parsed as their media type
>    that is using the +xml suffix.  [I-D.ietf-appsawg-media-type-regs]
>    defines a registry to be used for future Structured Syntax Suffixes.

    for future Structured Syntax Suffixes
    ->
    for such "Structured Syntax Suffixes"

>    A variety of Structured Syntax Suffixes have already been used in
>    some Media Type registration, in particular "+json", "+der",
>    "+fastinfoset" and "+wbxml".  This document defines and registers
>    these Structured Syntax Suffixes in the Structured Syntax Suffix

It might be worth introducing the string SSS to avoid repeating the full 
term so often.

> 2.  When to Use these Structured Syntax Suffixes
>
>    Each of the Structured Syntax Suffixes defined in this document are

    are  ->  is

>    appropriate for use when the media type identifies the semantics of
>    the protocol payload.  That is, knowing the semantics of the specific
>    media type provides for more specific processing of the content than
>    that afforded by generic processing of the underlying representation.
>
>    At the same time, using the suffix provides receivers of the media
>    types to do generic processing of the underlying representation in
>    cases where 1) they do not need to handle specially the particular

    they do not need to handle specially the particular
    ->
    they do not need to perform special handling of the particular

>    semantics of the exact media type, and, 2) there is no special
>    knowledge needed by such a generic processor in order to parse that
>    underlying representation other than what would be needed to parse
>    any example of that underlying representation.

#2 here is a rather long and somewhat awkward bit of text, but I haven't 
any clever (or even pedestrian) ideas of how to change it for the better.

> 3.  The +json Structured Syntax Suffix

An unfortunate place for a page break, of course...

A small nit in document organization is that I would expect the specific 
SSSs listed here to be sub-sections of a single section.  That is, 
something like:

    3. Initial Structured Syntax Suffix Definitions

       3.1  The +json Structured Syntax Suffix
       3.2  The +ber and +der Structured Syntax Suffixes
       3.3  The +fastinfoset Structured Syntax Suffix
       ...

I think it produces a cleaner Table of Contents.

>
>
> Hansen                  Expires October 26, 2012                [Page 2]
> 
> Internet-Draft       Additional Media Type Suffixes           April 2012
>
>
>    [RFC4627] defines the "application/json" media type.  The suffix
>    "+json" may be used with any media type whose representation follows

    may  -> can   {heh}

>    that established for "application/json".  The Message Type Structured
>    Syntax Suffix registration form follows:

I think this is the first use of "Message Type Structured Syntax 
Suffix".  It needs to be introduced/defined earlier on its own.

>    Name                JavaScript Object Notation (JSON)
>
>    +suffix             +json
>
>    References          [RFC4627]
>
>    Encoding considerations Per [RFC4627], JSON may be represented using
>                        UTF-8, UTF-16, or UTF-32.  When JSON is written
>                        in UTF-8, JSON is 8bit compatible.  When JSON is
>                        written in UTF-16 or UTF-32, JSON is binary.

If you mean 8bit and binary as MIME terms, they should be introduced as 
such.  If you don't mean them as MIME, then isn't 8bit a form of binary 
too?  Seriously, if this isn't MIME-related, I don't know what formal 
formal distinction is meant.

{ BTW - Shouldn't the hanging indent paragraphs have a colon separating 
the paragraph label from the paragraph content? }

>    Fragment identifier considerations Media types using "+json" SHOULD

What is a 'fragment identifier'?  I don't see it defined.  Even if it's 
fairly easy to guess it's meaning, guessing should not be required.

>                        process any fragment identifiers defined for
>                        "application/json" in the same way as defined for
>                        that media type.  (At publication of this
>                        document, there is no fragment identification
>                        syntax defined for "application/json".) Specific
>                        media types using "+json" MAY identify additional
>                        fragment identifier considerations, MAY define
>                        processing for fragment identifiers that are
>                        classed as errors for "application/json" and MAY
>                        designate fragment identifiers defined for
>                        "application/json" that SHOULD NOT be used.

These normative statements seem a bit ominous and possibly confusing, 
absent particulars or, at least, examples.  Offhand, I don't have a 
guess about possible additional frag id considerations, for example.

As an exercise, consider leaving all three of these normative assertions 
off.  What does that change?  Are there implied prohibitions that would 
then apply -- since the normative assertions explicitly give additional 
permission?  I don't think so.

>    Interoperability considerations n/a
>
>    Security considerations See [RFC4627]
>
>    Contact             Apps Area Working Group ([email-masked])
>
>    Author/Change controller The Apps Area Working Group has change
>                        control over this registration.
>
> 4.  The +ber and +der Structured Syntax Suffixes

Given their origin, grouping these is understandable.  However these are 
  distinct suffixes and it would be cleaner to list them separately.

>    The ITU defined the Basic Encoding Rules (BER) and Distinguished
>    Encoding Rules (DER) message transfer syntaxes in [ITU.X690.2008].
>    The suffix "+ber" may be used with any media type whose
>    representation follows the BER message transfer syntax.  The suffix
>    "+der" may be used with any media type whose representation follows
>    the DER message transfer syntax.  The Message Type Structured Syntax
>    Suffix registration forms follows:
>
>    Name                Basic Encoding Rules (BER) message transfer
>                        syntax
>
>    +suffix             +ber
>
>
> Hansen                  Expires October 26, 2012                [Page 3]
> 
> Internet-Draft       Additional Media Type Suffixes           April 2012
>
>
>    References          [ITU.X690.2008]
>
>    Encoding considerations BER is a binary encoding.
>
>    Fragment identifier considerations n/a
>
>    Interoperability considerations n/a
>
>    Security considerations There are no security considerations inherent
>                        in BER.  Each individual media type registered
>                        with a +ber suffix may have additional security
>                        considerations.
>
>    Contact             Apps Area Working Group ([email-masked])
>
>    Author/Change controller The Apps Area Working Group has change
>                        control over this registration.
>
>    Name                Distinguished Encoding Rules (DER) message
>                        transfer syntax
>
>    +suffix             +der
>
>    References          [ITU.X690.2008]
>
>    Encoding considerations DER is a binary encoding.
>
>    Fragment identifier considerations n/a
>
>    Interoperability considerations n/a
>
>    Security considerations There are no security considerations inherent
>                        in DER. Each individual media type registered
>                        with a +der suffix may have additional security
>                        considerations.
>
>    Contact             Apps Area Working Group ([email-masked])
>
>    Author/Change controller The Apps Area Working Group has change
>                        control over this registration.
>
> 5.  The +fastinfoset Structured Syntax Suffix
>
>    The ITU defined the Fast Infoset document format as a binary
>
>
>
>
>
>
>
>
>
>
> Hansen                  Expires October 26, 2012                [Page 4]
> 
> Internet-Draft       Additional Media Type Suffixes           April 2012
>
>    representation of the XML Information Set in [ITU.X891.2005].  These
>    documents further define the "application/fastinfoset" media type.
>    The suffix "+fastinfoset" may be used with any media type whose
>    representation follows that established for "application/
>    fastinfoset".  The Message Type Structured Syntax Suffix registration
>    form follows:
>
>    Name                Fast Infoset document format
>
>    +suffix             +fastinfoset
>
>    References          [ITU.X891.2005]
>
>    Encoding considerations Fast Infoset is a binary encoding.  The
>                        binary, quoted-printable and base64 content-
>                        transfer-encodings are suitable for use with Fast
>                        Infoset.
>
>    Fragment identifier considerations Media types using "+fastinfoset"
>                        SHOULD process any fragment identifiers defined
>                        for "application/fastinfoset" in the same way as
>                        defined for that media type.  (At publication of
>                        this document, there is no fragment
>                        identification syntax defined for "application/
>                        fastinfoset".) Specific media types using
>                        "+fastinfoset" MAY identify additional fragment
>                        identifier considerations, MAY define processing
>                        for fragment identifiers that are classed as
>                        errors for "application/fastinfoset" and MAY
>                        designate fragment identifiers defined for
>                        "application/fastinfoset" that SHOULD NOT be
>                        used.
>
>    Interoperability considerations n/a
>
>    Security considerations There are no security considerations inherent
>                        in Fast Infoset.  Each individual media type
>                        registered with a +fastinfoset suffix may have
>                        additional security considerations.
>
>    Contact             Apps Area Working Group ([email-masked])
>
>    Author/Change controller The Apps Area Working Group has change
>                        control over this registration.
>
> 6.  The +wbxml Structured Syntax Suffix
>
>    The WAP Forum has defined the WAP Binary XML (WBXML) document format
>    as a binary representation of XML in [WBXML].  This document further
>    defines the "application/vnd.wap.wbxml" media type.  The suffix
>    "+wbxml" may be used with any media type whose representation follows
>    that established for "application/vnd.wap.wbxml".  The Message Type
>    Structured Syntax Suffix registration form follows:
>
>
> Hansen                  Expires October 26, 2012                [Page 5]
> 
> Internet-Draft       Additional Media Type Suffixes           April 2012
>
>
>    Name                WAP Binary XML (WBXML) document format
>
>    +suffix             +wbxml
>
>    References          [WBXML]
>
>    Encoding considerations WBXML is a binary encoding.
>
>    Fragment identifier considerations Media types using "+wbxml" SHOULD
>                        process any fragment identifiers defined for
>                        "application/vnd.wap.wbxml" in the same way as
>                        defined for that media type.  (At publication of
>                        this document, there is no fragment
>                        identification syntax defined for "application/
>                        vnd.wap.wbxml".) Specific media types using
>                        "+wbxml" MAY identify additional fragment
>                        identifier considerations, MAY define processing
>                        for fragment identifiers that are classed as
>                        errors for "application/vnd.wap.wbxml" and MAY
>                        designate fragment identifiers defined for
>                        "application/vnd.wap.wbxml" that SHOULD NOT be
>                        used.
>
>    Interoperability considerations n/a
>
>    Security considerations There are no security considerations inherent
>                        in WBXML.  Each individual media type registered
>                        with a +wbxml suffix may have additional security
>                        considerations.
>
>    Contact             Apps Area Working Group ([email-masked])
>
>    Author/Change controller The Apps Area Working Group has change
>                        control over this registration.
>
> 7.  The +zip Structured Syntax Suffix

Shouldn't there also be a +gzip definition...?

>    The ZIP format is a public domain, cross-platform, interoperable file
>    storage and transfer format, originally defined by PKWARE, Inc.; it
>    supports compression and encryption and is used as the underlying
>    representation by a variety of file formats.  The media type
>    "application/zip" has been registered for such files.  The suffix
>    "+zip" may be used with any media type whose representation follows
>    that established for "application/zip".  The Message Type Structured
>    Syntax Suffix registration form follows:
>
>    Name                ZIP file storage and transfer format
>
>    +suffix             +zip
>
>    References          [ZIP]
>
>
>
> Hansen                  Expires October 26, 2012                [Page 6]
> 
> Internet-Draft       Additional Media Type Suffixes           April 2012
>
>    Encoding considerations ZIP is a binary encoding.
>
>    Fragment identifier considerations Media types using "+zip" SHOULD
>                        process any fragment identifiers defined for
>                        "application/zip" in the same way as defined for
>                        that media type.  (At publication of this
>                        document, there is no fragment identification
>                        syntax defined for "application/zip".) Specific
>                        media types using "+zip" MAY identify additional
>                        fragment identifier considerations, MAY define
>                        processing for fragment identifiers that are
>                        classed as errors for "application/zip" and MAY
>                        designate fragment identifiers defined for
>                        "application/zip" that SHOULD NOT be used.
>
>    Interoperability considerations n/a
>
>    Security considerations ZIP files support two forms of encryption:
>                        Strong Encryption and AES 128-bit, 192-bit and
>                        256-bit encryption; see the specification for
>                        further details.  Each individual media type
>                        registered with a +zip suffix may have additional
>                        security considerations.
>
>    Contact             Apps Area Working Group ([email-masked])
>
>    Author/Change controller The Apps Area Working Group has change
>                        control over this registration.
>
> 8.  IANA Considerations
>
>    See the Message Type Structured Syntax Suffix registration forms in
>    Section 3 - Section 7.
>
>    The existing Structured Syntax Suffix registration for "+xml" should
>    be modified to include the following
>
>    Fragment identifier considerations Media types using "+xml" SHOULD
>                        process any fragment identifiers defined for
>                        "application/xml" in the same way as defined for
>                        that media type.  (At publication of this
>                        document, the fragment identification syntax
>                        considerations for "application/xml" are defined
>                        in [RFC3023].) Specific media types using "+xml"
>                        MAY identify additional fragment identifier
>                        considerations, MAY define processing for
>                        fragment identifiers that are classed as errors
>                        for "application/xml" and MAY designate fragment
>                        identifiers defined for "application/xml" that
>                        SHOULD NOT be used.
>
> 9.  Security Considerations
>
>
>
> Hansen                  Expires October 26, 2012                [Page 7]
> 
> Internet-Draft       Additional Media Type Suffixes           April 2012
>
>
>    See the Security considerations sections found in the Message Type
>    Structured Syntax Suffix registration forms from Section 3 - Section
>    6.
>
> 10.  References
>
> 10.1.  Normative References
>
>    [RFC4627]  Crockford, D., "The application/json Media Type for
>               JavaScript Object Notation (JSON)", RFC 4627, July 2006.
>
>    [ITU.X690.2008]
>               International Telecommunications Union, "Recommendation
>               ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules:
>               Specification of basic encoding Rules (BER), Canonical
>               encoding rules (CER) and Distinguished encoding rules
>               (DER)", ITU-T Recommendation X.690, November 2008.
>
>    [ITU.X891.2005]
>               International Telecommunications Union, "Recommendation
>               ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications
>               of ASN.1: Fast infoset", ITU-T Recommendation X.891, May
>               2005.
>
>    [WBXML]    Open Mobile Alliance, "Binary XML Content Format
>               Specification", OMA Wireless Access Protocol
>               WAP-192-WBXML-20010725-a, July 2001.
>
>    [ZIP]      PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format
>               Specification", PKWARE .ZIP File Format Specification -
>               Version 6.3.2, September 2007.
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [RFC3023]  Murata, M., St.  Laurent, S. and D. Kohn, "XML Media
>               Types", RFC 3023, January 2001.
>
> 10.2.  Informative References
>
>    [I-D.ietf-appsawg-media-type-regs]
>               Freed, N., Klensin, J. and T. Hansen, "Media Type
>               Specifications and Registration Procedures", Internet-
>               Draft draft-ietf-appsawg-media-type-regs-05, April 2012.
>
> Appendix A.  Change History
>
>    This section is to be removed before publication.
>
>    draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment
>                        identifier consideration sections.
>                        Added a note about +xml fragment identifier
>                        considerations.
>
> Hansen                  Expires October 26, 2012                [Page 8]
> 
> Internet-Draft       Additional Media Type Suffixes           April 2012
>
>
>    draft-hansen-media-type-suffix-regs-02 Added +zip.
>                        Fixed up the ISO document references.
>                        Minor changes.
>
>    draft-hansen-media-type-suffix-regs-01 Added +ber.
>                        Minor changes.
>
> Author's Address
>
>    Tony Hansen
>    AT&T Laboratories
>    200 Laurel Ave. South
>    Middletown, NJ 07748
>    USA
>
>    Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hansen                  Expires October 26, 2012                [Page 9]

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 May 2012 13:08:23 -0400

Thanks Dave!

I agree with most of your suggestions. A few comments below on specific 
items.

     Tony Hansen

On 5/17/2012 11:49 AM, Dave Crocker wrote:
> It might be worth introducing the string SSS to avoid repeating the 
> full term so often.

I chose not to do this.

> #2 here is a rather long and somewhat awkward bit of text, but I 
> haven't any clever (or even pedestrian) ideas of how to change it for 
> the better.

I've split it into an actual <list>, which will make it appear less odious.

> If you mean 8bit and binary as MIME terms, they should be introduced 
> as such.  If you don't mean them as MIME, then isn't 8bit a form of 
> binary too?  Seriously, if this isn't MIME-related, I don't know what 
> formal formal distinction is meant.

I added the MIME reference.

> What is a 'fragment identifier'?  I don't see it defined.  Even if 
> it's fairly easy to guess it's meaning, guessing should not be required.

I added a reference to the definition of the registration form in 
draft-ietf-appsawg-media-type-regs. I don't think it's appropriate to 
repeat all of that in this document.

> As an exercise, consider leaving all three of these normative 
> assertions off.  What does that change?  Are there implied 
> prohibitions that would then apply -- since the normative assertions 
> explicitly give additional permission?  I don't think so.

The phrasing of this came about after extensive discussion over 
draft-ietf-appsawg-media-type-regs.

> Shouldn't there also be a +gzip definition...?

This is worthy of a separate discussion on apps-discuss.

     Tony

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 May 2012 13:23:45 -0400

One of the comments that Dave makes in his review of 
draft-ietf-appsawg-media-type-suffix-regs-00 (Additional Media Type 
Structured Syntax Suffixes ) is

> Shouldn't there also be a +gzip definition...?

What do people think about this suggestion? Would it be useful to have 
+gzip defined as a Media Type Structured Syntax Suffix?

In particular, who would use it?

Almost every one of the other suffixes in the draft already have sample 
uses in the wild, but I haven't seen any +gzip suffixes in the wild (or 
+deflate for that matter).

Thoughts?

     Tony Hansen

---

From: "John Levine" <[email-masked]>
Date: 17 May 2012 17:43:31 -0000

>+deflate for that matter).

They're both content coding options for Accept-Encoding: in http, and
I think are fairly popular there.  That's probably why you don't see
them in media types.  Or else applications intuit them in other ways,
e.g., a file name that ends with .tgz.

I presume you're aware that my draft defining application/gzip and
application/deflate is in last call.  I agree that in a more perfect
world MIME would have better ways to describe compressed encodings,
but when I noticed that DMARC picked application/zip mostly because it
was already registered, I figured they deserved equal time.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 10:43:13 -0700 (PDT)

> Thoughts?

Although I don't believe any of them use the +zip suffix, there are plenty of
examples of media types where the content is structured as a bunch of separate
objects packed inside of a zip container. So +zip at least makes sense.

The key to the use of such techniques seems to be both that it compresses *and*
it's capable of storing multiple objects. So there is some argument that
+deflate is unlikely to be used. (+tar would the opposite side of the coin.)

The gzip file format (RFC 1952), OTOH, certainly supports the concept of
multiple objects. Why zip seems to be prefered, I have no idea, but in my
experience at least that seems to be the case. But since we have a
specification RFC for both deflate and the gzip file format, I see no reason
not to define +gzip.

I also note that while deflate makes sense as part or all of a transfer
encoding, gzip file format does not.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 10:58:21 -0700 (PDT)

> repeat all of that in this document.

If you want to reference the place where fragment identifiers are defined, that
would be RFC 3986 section 3.5.

As a side note, I'm going to change the reference in the media types
registration document to include the specific section.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 May 2012 14:22:59 -0400

> objects packed inside of a zip container. So +zip at least makes sense.

application/epub+zip

     Tony

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 May 2012 14:27:52 -0400

> registration document to include the specific section.

Actually, I don't think it's appropriate for this document. It's 
certainly appropriate for the media types registration document to have 
the reference. But I don't think it's appropriate for the suffix 
registration document that implements that piece to repeat all of those 
definitions.

     Tony Hansen

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 13:28:53 -0700 (PDT)

> application/epub+zip

Missed that one; sorry.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 May 2012 14:40:32 -0700 (PDT)

> registration document that implements that piece to repeat all of those

WFM.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 May 2012 17:52:18 -0400 (EDT)

wfm. tnx.

d/

  via mobile

-----Original Message-----
From: Tony Hansen <[email-masked]>
To: [email-masked]
Cc: Dave Crocker <[email-masked]>, [email-masked], iesg <[email-masked]>
Sent: Thu, 17 May 2012 10:08 AM
Subject: Re: Review of: draft-ietf-appsawg-media-type-suffix-regs-00

Thanks Dave!

     Tony Hansen

I chose not to do this.

     Tony

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 May 2012 17:52:18 -0400 (EDT)

wfm. tnx.

d/

  via mobile

-----Original Message-----
From: Tony Hansen <[email-masked]>
To: [email-masked]
Cc: Dave Crocker <[email-masked]>, [email-masked], iesg <[email-masked]>
Sent: Thu, 17 May 2012 10:08 AM
Subject: Re: Review of: draft-ietf-appsawg-media-type-suffix-regs-00

Thanks Dave!

     Tony Hansen

I chose not to do this.

     Tony

---

From: "John Levine" <[email-masked]>
Date: 17 May 2012 22:49:49 -0000

>experience at least that seems to be the case.

While it is true that the gzip format supports multiple objects, all
of the gzip software I have ever used treats it as a stream
compressor, at most picking out the first filename to use as the name
of the decompressed file.  The usual convention on Unix systems is to
bundle up multiple files into a tar archive and gzip that, which the
standard tar program will do in one pass.  tgz files still have the
advantage over zip files that you can decode and extract files from
them on the fly since the directory info is interleaved with the data
rather than all stored at the end.

I'm agnostic about +gzip or +deflate.  If people want them, it's OK
with me.

R's,
John

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 18 May 2012 17:52:42 +0900

If nobody is using +gzip or whatever, I'd just leave them alone. Once 
there's a need, they can always be added.      Regards,    Martin.

On 2012/05/18 7:49, John Levine wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>