Subject: Re: IANA Considerations

From: [email-masked]
Date: Mon, 3 May 1999 15:52:44 -0400

This is good but I believe some minor wording change is still needed.  In
particular:

On the mailing list: RFCs can not assume the perpertual existence of a working
group.  It can say the IETF Trade Mailing List, but it can't say the Trade WG
Mailing List.  The actual mailing list address should be given
<[email-masked]>.

On the Designated Expert, it should probably explicitly say they are appointed
by the IESG.  While the TRADE WG exists, the IESG is likely to defer to the WG
on whom to appoint but there needs to be a mechaism that would survive the
termination of the working group.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 04/28/99 05:45:37 PM

To:   Ietf Trade WG <[email-masked]>
cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  IANA Considerations

Below is the revised text for IANA considerations for the IOTP
specification. Essentially it consists of a re-worked section 3.7.3 from the
last draft as a new section 11.

If anyone has any comments please let me know.

David
========================
11. IANA Considerations

11.1 Codes Controlled by IANA

To help ensure interoperability, there is  a need for codes  used
by IOTP  to be  maintained in  a controlled  environment so  that
their meaning  and usage  are well  defined and  duplicate  codes
avoided. [IANA] is the mechanism to  be used for this purpose  as
described in RFC 2434.

The element types  and attributes names  to which this  procedure
applies is shown  in the table  below together  with the  initial
values that are valid for these attributes.

  Element Type/                      Attribute Values
 Attribute Name

Algorithm/        "sha1" - indicates that authentication consists of
Name              [SHA1] has of the challenge data
(When Algorithm
is a child of an  "signature" - indicates that authentication consists
AuthData          of the generation of a digital signature.
component)
                  "Pay:ppp" where "ppp" may be set to any valid value
                  for "iotpbrand" (see below)

                  With the exception of Authentication Methods that
                  begin with "pay:", new values are allocated
                  following review on the IETF Trade Working Group
                  mailing list and by the Designated Expert.

                  [Note]   The Algorithm element is likely to be
                           eventually defined within the [DSIG] name
                           space. It is likely that the maintenance
                           procedure defined here may need to vary
                           over time, as the DSIG proposals become
                           more widely adopted.
                  [Note End]

Brand/BrandId     "SET:setbrand" where setbrand is a brand which is
                  accepted by the [SET] payment protocol

                  "IOTP:iotpbrand" where iotpbrand may be:
                  o "GeldKarte"
                  o "Mondex"

                  New values of the high level prefix (SET or IOTP)
                  are allocated following review on the IETF Trade
                  Working Group mailing list and by the Designated
                  Expert.

                  Values of "setbrand" are allocated as defined in the
                  [SET] specifications.

                  New values of "iotpbrand" must be announced to the
                  IETF Trade WG mailing list and, if there are no
                  objections within three weeks, are allocated on a
                  "first come first served" basis.

CurrencyAmount/   Currency codes are dependent on CurrCodeType (see
CurrCode          below).

                  If CurrCodeType is "ISO4217-A" then the currency
                  code is an alphabetic code as defined by [ISO4217]

                  If CurrCodeType is "IOTP" then new values must be
                  announced to the IETF Trade WG mailing list and, if
                  there are no objections within three weeks, are
                  allocated on a "first come first served" basis.

                  [Note]   The Currency Code Type of IOTP, is designed
                           to allow the support of "new" psuedo
                           currencies such as loyalty or frequent
                           flyer points. At the time of writing this
                           specification, no currency codes of this
                           type have been defined.
                  [Note End]

CurrencyAmount/   "ISO4217-A"
CurrCodeType
                  "IOTP"

                  New values of CurrCodeType attribute are allocated
                  following review on the IETF Trade Working Group
                  mailing list and by the Designated Expert.

DeliveryData/     "Post"
DelivMethod
                  "Web"

                  "Email"

                  New values of Delivery Method attribute are
                  allocated following review on the IETF Trade Working
                  Group mailing list and by the Designated Expert.
                  This may require the publication of additional
                  documentation to describe how the delivery method is
                  used.

PackagedContent/  "PCDATA"
Content
                  "MIME"

                  "MIME:mimetype" (where mimetype must be the same as
                  content-type as defined by [MIME] )

                  "XML"

                  If the Content attribute is of the form
                  "MIME"mimetype", then control of new values for
                  "mimetype" is as defined in [MIME].

                  Otherwise, new values of the Content attribute are
                  allocated following review on the IETF Trade Working
                  Group mailing list and by the Designated Expert.
                  This may require the publication of additional
                  documentation to describe how the new attribute is
                  used within a Packaged Content element.

RelatedTo/        "OtpTransaction"
RelationshipType
                  "Reference"

                  New values of the RelationshipType attribute are
                  allocated following review on the IETF Trade Working
                  Group mailing list and by the Designated Expert.
                  This may require the publication of additional
                  documentation to describe how the delivery method is
                  used.

Status/           Offer
StatusType
                  Payment

                  Delivery

                  Authentication

                  New values of the Status Type attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange, Trading Roles
                    and associated components that relate to the
                    Status, and
                  o review of the document on the IETF Trade Working
                    Group mailing list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           Status Type attribute may be combined with
                           documents that describe new Trading Roles
                           and types of signatures (see below).
                  [Note End]

TradingRole/      "Consumer"
TradingRole
                  "Merchant"

                  "PaymentHandler"

                  "DeliveryHandler"

                  "DelivTo"

                  "CustCare"

                  New values of the Trading Role attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange, Trading Roles
                    and associated components that relate to the
                    Trading Role, and
                  o review of the document on the IETF Trade Working
                    Group mailing list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           Trading Role attribute may be combined with
                           documents that describe new Status Types
                           (see above) and types of signatures (see
                            below).
                  [Note End]

TransId/          "BaselineAuthentication"
OtpTransType
                  "BaselineDeposit"

                  "BaselinePurchase"

                  "BaselineRefund"

                  "BaselineWithdrawal"

                  "BaselineValueExchange"

                  "BaselineInquiry"

                  "BaselinePing"

                  New values of the OtpTransType attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the new IOTP Transaction, and
                  o review of the document on the IETF Trade Working
                   Group mailing list and by the Designated Expert.

Attribute/        "OfferResponse"
Content
(see Signature    "PaymentResponse"
Component)
                  "DeliveryResponse"

                  "AuthenticationRequest"

                  "AuthenticationResponse"

                  "PingRequest"

                  "PingResponse"

                  New values of the code that define the type of a
                  signature are allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange where the
                    signature is being used, and
                  o review of the document on the IETF Trade Working
                    Group mailing list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           types of signatures may be combined with
                           documents that describe new Status Types
                           and Trading Roles (see above).
                  [Note End]

11.2 Codes not controlled by IANA

In addition to the formal  development and registration of  codes
as described  above, there  is still  a  need for  developers  to
experiment using new IOTP codes.  For this reason, "user  defined
codes" may be used  to identify additional  values for the  codes
contained within this specification without the need for them  to
be registered with IANA.

The definition of a user defined code is as follows:

user_defined_code ::= ( "x-" | "X-" ) NameChar(NameChar)*

NameChar            NameChar  has the  same definition  as the  [XML]
                    definition of NameChar

Use of domain names (see [DNS]) to make user defined codes unique
is recommended although this method cannot be relied upon.
===================================================

THIS EMAIL IS FOR UNLIMITED DISTRIBUTION

> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
>

*******************************************************************************************

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: David Burdett <[email-masked]>
Date: Wed, 5 May 1999 20:10:38 +0100

Noted

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	03 May 1999 12:52
> To: 	Ietf Trade WG
> Subject: 	Re: IANA Considerations
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************