Re: [jose] Should we delete the "typ" header field

It is giving the meaning to the signature - metadata about the signature,
so I thought header would be more appropriate, besides, the payload is
binary and I can avoid double base64 encoding that way.

2013/6/6 Dick Hardt <dick.hardt@gmail.com>

> Why would you need that in the header? Why not in the payload?
>
>
> On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura <sakimura@gmail.com> wrote:
>
>> What I was thinking as an example was to have 'datetime' as a public
>> header parameter to be used generally, and then differentiate between two
>> cases of 'agreement' and 'timestamp'. It is the same signing operation over
>> the original (e.g., a MS word document), but from an application point of
>> view, it is a bit different. Former constitute an agreement while the later
>> does not. The type=timestamp just signifies that the original document
>> existed at the time indicated.
>>
>>
>> 2013/6/5 Richard Barnes <rlb@ipv.sx>
>>
>>> I'm not sure I understand the use case here.  Let me look at a couple of
>>> options, and hopefully one of them will be what you meant :)
>>>
>>> If it's just a signed timestamp you're talking about, then that's
>>> adequately described by cty="timestamp", typ="JWS".
>>>
>>> If you want to sign something and add a timestamp in the header, then
>>> typ="timestamp" isn't accurate according to the current specification.  The
>>> type of the whole object would have to be something like
>>> "timestamped-content".  And in that case, an application can easily
>>> recognized that it's timestamped content by looking for the timestamp field
>>> in the header, so the "typ" isn't really helpful.
>>>
>>>
>>> Moving from the example to the general question:
>>>
>>> I think we finally have some common understanding on this list as to
>>> what Mike means by "typ" in the current document -- a label for the
>>> application-layer type of the overall object.  Thanks to Mike for
>>> clarifying that in this discussion.
>>>
>>> The question is whether this is a sufficiently useful thing to have in
>>> the core spec.  Obviously, applications have to know what type of object
>>> they're dealing with when they get a JOSE object.  That includes (1) what
>>> type of content is in the payload, and (2) what application-layer fields
>>> are required to be in the header.  (1) is covered by "cty".  So "typ" is
>>> only useful in the case where:
>>> A. The application is storing application-layer data in the JOSE header
>>> B. The required application-layer fields can be different for different
>>> objects
>>> C. The required application-layer fields can be different for different
>>> objects of the same content type
>>> D. The required application-layer fields are not indicated by other
>>> application-layer context
>>>
>>> Are there any known applications that meet these criteria?  JWT does
>>> not, for several reasons.
>>> 1. (!A) JWT does not store application-layer data in the JOSE header,
>>> only in the claims in the body
>>> 2. (!C) A JWT object can indicate with "cty" that it contains JWT claims
>>> or another JWT, either of which makes it obvious that this is a JWT
>>> 3. (!D) In the OAuth context, the Token Type value indicates what type
>>> of token is being presented, e.g., JWT
>>>
>>> So there's not really any known use case for "typ" as currently
>>> specified.  On the other hand, Dick and James have pointed out that it can
>>> be useful to have "typ" indicate whether the object at hand is a JWE or
>>> JWS.  Which brings us back to:
>>> -- Change the definition of "typ" so that it indicates the JOSE-layer
>>> type (JWE/JWS)
>>> -- Remove "typ" altogether
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>>>
>>>> What about such as this?
>>>>
>>>> cty: original
>>>> typ: timestamp
>>>>
>>>>
>>>> 2013/6/5 Richard Barnes <rlb@ipv.sx>
>>>>
>>>>> It would be a good point, if it were true :)  In particular, this
>>>>> part: "[dropping 'typ'] is going to cause each and every application
>>>>> that uses JOSE to define their own field"
>>>>>
>>>>> So far, I've heard of exactly one application of JOSE that requires
>>>>> "typ" in the way it is currently specified, namely JWT.
>>>>>
>>>>> On the other hand, Dick's applications are apparently using it
>>>>> differently (and, IMO, properly) to distinguish JWE/JWS.  Then there are
>>>>> all the applications out there that are OK using application context and
>>>>> "cty" to recognize what type of object they have.  Apps using CMS have been
>>>>> doing this for ages.
>>>>>
>>>>> So it's not at all clear to me that there's any other application that
>>>>> would use "typ" besides JWT.  And it's not clear to me that JWT needs it.
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 31, 2013 at 5:45 PM, Brian Campbell <
>>>>> bcampbell@pingidentity.com> wrote:
>>>>>
>>>>>> Nat makes a good point here, I think.
>>>>>>
>>>>>>
>>>>>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <sakimura@gmail.com>wrote:
>>>>>>
>>>>>>> From what I understand, both typ and cty are something to be
>>>>>>> consumed by the application and not JOSE processor. From the point of view
>>>>>>> of the JOSE processor, they should be ignored.
>>>>>>>
>>>>>>> We could drop both fields from JOSE specs, but that is going to
>>>>>>> cause each and every application that uses JOSE to define their own field,
>>>>>>> which is a waste. That is why we are defining them here.
>>>>>>>
>>>>>>> I would rather drop them than define JOSE processing semantics to
>>>>>>> these fields.
>>>>>>>
>>>>>>>
>>>>>>> 2013/5/31 Mike Jones <Michael.Jones@microsoft.com>
>>>>>>>
>>>>>>>>  No, “cty” is used by the derived class to determine the type of
>>>>>>>> the encapsulated field.  But that’s not a complete description of the *
>>>>>>>> *entire object** - especially not the additional meaning imbued by
>>>>>>>> the additional parameters the derived type may add to the JOSE header.
>>>>>>>> “typ” is there to provide the type of the entire object, including what
>>>>>>>> you’re calling the wrapper parts.****
>>>>>>>>
>>>>>>>> ** **
>>>>>>>>
>>>>>>>>                                                             -- Mike
>>>>>>>> ****
>>>>>>>>
>>>>>>>> ** **
>>>>>>>>
>>>>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx]
>>>>>>>> *Sent:* Thursday, May 30, 2013 7:58 AM
>>>>>>>>
>>>>>>>> *To:* Mike Jones
>>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt
>>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>>>>>>
>>>>>>>> ** **
>>>>>>>>
>>>>>>>> Isn't that requirement met by "cty"?  The only thing JOSE adds is a
>>>>>>>> crypto wrapper around the real application content.  If you're an
>>>>>>>> application, you know a JOSE object is the thing you want because it
>>>>>>>> contains the content you want -- it's a JWT because it contains JWT claims.
>>>>>>>> ****
>>>>>>>>
>>>>>>>> ** **
>>>>>>>>
>>>>>>>> Inheritance is the wrong metaphor.  This is encapsulation of
>>>>>>>> application data:****
>>>>>>>>
>>>>>>>> if (jws.valid && jws.cty == "application/jwt_claims") {****
>>>>>>>>
>>>>>>>>     jwtClaims = jws.content;****
>>>>>>>>
>>>>>>>> }****
>>>>>>>>
>>>>>>>> ** **
>>>>>>>>
>>>>>>>> --Richard****
>>>>>>>>
>>>>>>>> ** **
>>>>>>>>
>>>>>>>> On Thu, May 30, 2013 at 10:43 AM, Mike Jones <
>>>>>>>> Michael.Jones@microsoft.com> wrote:****
>>>>>>>>
>>>>>>>> Thanks for sharing the S/MIME details.  Although I was actually
>>>>>>>> making the analogy to MIME – not S/MIME.  Like many analogies, it’s
>>>>>>>> imperfect, but I believe still illustrative.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> The reason that the analogy isn’t perfect is that the JOSE data
>>>>>>>> structures are used to build application-specific data structures that are
>>>>>>>> legal JOSE data structures but also have additional properties – including
>>>>>>>> additional header fields with specific semantics.  (When we agreed to
>>>>>>>> ignore not-understood header fields we let that horse out of the barn.)
>>>>>>>> For instance, Dick Hardt uses JWEs with issuer and audience fields in the
>>>>>>>> headers, so they can be used by routing software.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Think of JOSE as the base class and the application types built
>>>>>>>> using it as derived classes.  JWT is a derived class.  Dick’s structures
>>>>>>>> are a derived class.  These derived classes sometimes need names.  That’s
>>>>>>>> what “typ” is for.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>                                                             -- Mike
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx]
>>>>>>>> *Sent:* Thursday, May 30, 2013 7:34 AM****
>>>>>>>>
>>>>>>>>
>>>>>>>> *To:* Mike Jones
>>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt
>>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> You're mixing up "typ" and "cty".  If you want to make the analogy
>>>>>>>> to S/MIME, "cty" is the equivalent to Content-Type inside the protected
>>>>>>>> MIME body; "typ" is the content-type on the outer MIME header.  Pasting in
>>>>>>>> an example:****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> -----BEGIN-----****
>>>>>>>>
>>>>>>>> Content-Type: application/pkcs7-mime; smime-type=signed-data;****
>>>>>>>>
>>>>>>>>      name=smime.p7m****
>>>>>>>>
>>>>>>>> Content-Transfer-Encoding: base64****
>>>>>>>>
>>>>>>>> Content-Disposition: attachment; filename=smime.p7m****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7****
>>>>>>>>
>>>>>>>> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH****
>>>>>>>>
>>>>>>>> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh****
>>>>>>>>
>>>>>>>> 6YT64V0GhIGfHfQbnj75****
>>>>>>>>
>>>>>>>> -----END-----****
>>>>>>>>
>>>>>>>> <http://tools.ietf.org/html/rfc3851#section-3.4.2>****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> The outer Content-Type, which is analogous to "typ", MUST be
>>>>>>>> application/pkcs7-mime, with a parameter indicating the type of CMS object.
>>>>>>>>  This is the same as requiring "typ" to be JWE or JWS.  The inner
>>>>>>>> Content-Type (ASN.1/base64 encoded in the example) can be anything, just
>>>>>>>> like "cty".****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> --Richard****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> On Thu, May 30, 2013 at 12:53 AM, Mike Jones <
>>>>>>>> Michael.Jones@microsoft.com> wrote:****
>>>>>>>>
>>>>>>>> Requiring that the “typ” value be only “JWS” or “JWE” would be
>>>>>>>> analogous to the MIME spec requiring that the Content-Type: field be only
>>>>>>>> “text/plain” or “message/external-body”.  It would render it useless.
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>                                                             -- Mike
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On
>>>>>>>> Behalf Of *Richard Barnes
>>>>>>>> *Sent:* Wednesday, May 29, 2013 8:03 PM
>>>>>>>> *To:* Mike Jones
>>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt****
>>>>>>>>
>>>>>>>>
>>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> If this is the level of "type" you're referring to, I think we
>>>>>>>> should drop it from the spec.  It's an application-layer thing that the app
>>>>>>>> can add or not according to its wishes.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> I'm with Dick on this.  I think we should either have a mandatory
>>>>>>>> indicator of what type of JOSE object this, or nothing at all.   If the
>>>>>>>> former, the allowable values are "JWE" and "JWS".  The "+JSON" options are
>>>>>>>> non-sensical -- the app needs to know what it's parsing before it gets this
>>>>>>>> header.  While I have a preference for the former (for clarity), the latter
>>>>>>>> approach is also OK with me, since the MIME types are specific to JWE/JWS.
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Another approach here would be to address the JSON and compact
>>>>>>>> forms separately.  The JSON form has no need of "typ" at all, since the
>>>>>>>> type of the object is completely clear from what fields are there, e.g.,
>>>>>>>> "recipients" vs. "signatures".  For the compact form, we could do something
>>>>>>>> like James's "E."/"S." prefix idea, which you need because the
>>>>>>>> dot-separated components have different meanings and no field names to
>>>>>>>> indicate this.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> --Richard****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones <
>>>>>>>> Michael.Jones@microsoft.com> wrote:****
>>>>>>>>
>>>>>>>> A standard library is unlikely to know the meanings of all possible
>>>>>>>> “typ” values – and more to the point, *it doesn’t have to*.  It’s
>>>>>>>> the application’s job to determine that “this blob is a JOSE object” and
>>>>>>>> then pass it to a standard library, which will then ignore the “typ” value.
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> A standard JOSE library won’t know what “typ”: “JWT” means.  It
>>>>>>>> won’t know what “typ”: “BCGovToken” is, should the BC Government want to
>>>>>>>> declare that it’s using a token with particular characteristics.  It won’t
>>>>>>>> know what “typ”: “XMPP” is, should XMPP want to declare that it’s using a
>>>>>>>> JOSE data structure with particular characteristics.  Etc.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> All these values can be registered in the registry and used by
>>>>>>>> applications that understand them.  That’s the application’s job – not the
>>>>>>>> library’s job.  The “typ” field is just there so that applications have a
>>>>>>>> standard place to make any such declarations that they may need.***
>>>>>>>> *
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>                                                                 --
>>>>>>>> Mike****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com]
>>>>>>>> *Sent:* Wednesday, May 29, 2013 5:18 PM
>>>>>>>> *To:* Mike Jones
>>>>>>>> *Cc:* Jim Schaad; jose@ietf.org****
>>>>>>>>
>>>>>>>>
>>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> I'd prefer to be able to use standard libraries for creating and
>>>>>>>> parsing tokens, and not specialized libraries dependent on the use case.
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> I strongly think we either drop "typ" or make it required.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> On Wed, May 29, 2013 at 5:03 PM, Mike Jones <
>>>>>>>> Michael.Jones@microsoft.com> wrote:****
>>>>>>>>
>>>>>>>> It’s fine for your application to specify that it’s required for
>>>>>>>> your use case.  Not applications need it, so they shouldn’t be forced to
>>>>>>>> pay the space penalty of an unnecessary field.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>                                                                 --
>>>>>>>> Mike****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On
>>>>>>>> Behalf Of *Dick Hardt
>>>>>>>> *Sent:* Wednesday, May 29, 2013 4:56 PM****
>>>>>>>>
>>>>>>>>
>>>>>>>> *To:* Jim Schaad
>>>>>>>> *Cc:* jose@ietf.org
>>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> I use it all the time and my code would barf if it was not there.**
>>>>>>>> **
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> I think it should be required rather than be a hint if it is going
>>>>>>>> ot be there.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <ietf@augustcellars.com>
>>>>>>>> wrote:****
>>>>>>>>
>>>>>>>> I think the values just changed****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> However the way you are using it would be an argument to say that
>>>>>>>> it should be a required field.  Are you just using it as a hint if it
>>>>>>>> exists and then looking at the rest of the fields if it is not present?
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Jim****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com]
>>>>>>>> *Sent:* Wednesday, May 29, 2013 3:49 PM
>>>>>>>> *To:* Jim Schaad
>>>>>>>> *Cc:* jose@ietf.org
>>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Well, I have been using, but now realize the spec changed or I was
>>>>>>>> confused.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> I had been setting "typ" to be either "JWE" or "JWS" depending on
>>>>>>>> the type of token I was creating or parsing as it was easier than looking
>>>>>>>> at "alg"****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> As currently defined, I don't see value in "typ".****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> -- Dick****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.com>
>>>>>>>> wrote:****
>>>>>>>>
>>>>>>>> In reading the documents, I am trying to understand the
>>>>>>>> justification for having the “typ” header parameter in the JOSE documents.
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> The purpose of the field is to hold the type of the object.  In the
>>>>>>>> past, I believe that values which should now be placed in the cty field
>>>>>>>> (such as “JWT”) were placed in this field as well.  However the parameter
>>>>>>>> is optional and an implementation cannot rely on its being present.  This
>>>>>>>> means that for all practical purposes all of the code to determine the
>>>>>>>> value of the type field from the values of the alg and enc fields.  If the
>>>>>>>> field was mandatory then this code would disappear at a fairly small space
>>>>>>>> cost and I can understand why the parameter would be present.****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Can anybody justify why this field should be present in the
>>>>>>>> document – or should it just disappear?****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Jim****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jose mailing list
>>>>>>>> jose@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/jose****
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> --
>>>>>>>> -- Dick ****
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> --
>>>>>>>> -- Dick ****
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jose mailing list
>>>>>>>> jose@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/jose****
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> --
>>>>>>>> -- Dick ****
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jose mailing list
>>>>>>>> jose@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/jose****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> ** **
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jose mailing list
>>>>>>>> jose@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nat Sakimura (=nat)
>>>>>>> Chairman, OpenID Foundation
>>>>>>> http://nat.sakimura.org/
>>>>>>> @_nat_en
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jose mailing list
>>>>>>> jose@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>
>
>
> --
> -- Dick
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en