Subject: [drinks] on data validation...

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 29 Aug 2011 13:16:43 +0200

<wg chair hat off>

The concerns about the "unconstrained" elements were raised a long time
ago, and i admit it was a TODO on me that i never delivered - so let's
hope it's still useful now:

In preperation for the virtual interim, i've looked through the formal
schema specification of SPPP, checking which elements should have more
reasonable constraints added (compared to the current "everything goes"
policy). I've also found a few other things (listed below).

We have currently very little constraints on the various fields, which
means that a client could theoretically use a 8GB long blob of
unprintable unicode character codepoints as an object identifier. This
would obviously lead to a lot of problems, and hence (as indicated by
Dean and his developers), some constraints are required for
interopability.
Similar protocols in the IETF (most notably, EPP), have limited such
identifiers in a similar way  and are deployed in a broad fashion.
Quantitative and qualitative limitations help interopability (i'd even
go that far to say that protocols with no such limitations have unknown
interopability, because any test cannot be exhaustive).

Object Names
------------------

- I think that the various "names" and "keys" are the most important
ones to apply constraints on, since they are used as references between
objects, and used in comparison / lookup operations.

Therefore, i suggest to change the definition of ObjNameType from the
current

  <simpleType name="ObjNameType">
    <restriction base="string"/>
  </simpleType>

to the following definition

  <simpleType name="ObjNameType">
    <restriction base="token">
      <minLength value="3">
      <maxLength value="80">
    </restriction>
  </simpleType>

(note that the upper and lower limits are arbitrary - anybody willing to
offer a reasoning from practice? Also, more on "string" vs. "token" base
type below)

This affects, from what i can see, the following elements:

 - dgName
 - rrName
 - egrRteName
 - rgName

Transaction IDs
------------------

In a similar way, we should also restrict Transaction IDs. Those are
currently very "open" as well, and have the following definition:

  <simpleType name="TransIdType">
    <restriction base="string"/>
  </simpleType>

I do suggest to change those to:

  <simpleType name="TransIdType">
    <restriction base="token">
      <minLength value="3">
      <maxLength value="120">
    </restriction>
  </simpleType>

(note: I've seen that transaction ids tend to get longer than object
identifiers, so i extended my arbitrar length restrictions from the
ObjNameType above).

This restriction would affect the following elements:

 - clientTransId
 - serverTransId

Restrictions on E.164-derived elements
------------------------------------------------

The instances of the abstract public identifier object contain elements
that are derived from E.164 numbers. Since those are a namespace that is
very well defined and constrained, we should also look into constraining
the derived elements in SPPP. I do hence suggest to change the
definition of 

- tn
- rn
- startTN
- endTN
- tnPrefix

(all of them are currently defined as "string" with no additional length
constraints) to a specific Type (eg. "e164DerivedType"?). For
definitions, one option is to use the definition from RFC5105:

     <simpleType name="e164numberType">
       <restriction base="token">
         <maxLength value="20"/>
         <pattern value="\+\d\d*"/>
       </restriction>
     </simpleType>

However, i do understand that E.164 numbers can also use hexadecimal
characters "a-f", and hence the above definition would not allow those?
I haven't taken up the effort of checkign against E.164, but i'm sure
there are more knowledgeable people on the list... Any advice?

Organizations
----------------

Identifier of organizations are currently unrestricted as well. The
respective XML Schema definition is as follows:

  <simpleType name="OrgIdType">
    <restriction base="string"/>
  </simpleType>

I understand that since the namespace for those organizations will
probably come out of the GSPID work, or use some existing namespace, but
i think it will definitely need to be constrained (for the reasons
outlined above).

Base Type "string" vs "token"
------------------------------------

comparing the XML Schema definitions for "string" (base type) vs.
"token" base type, i'm pretty sure that we want all elements in our
protocol that contain textual contents to derive from the "token" base
type. The difference is that "string" base types allow for line feeds,
carriage returns, etc. Whitespace is significant. 

On the other hand, the "token" basetype does not allow for carriage
return, line feed, tab, leading and trailing spaces. 

http://www.w3.org/TR/xmlschema-2/#token

I cannot think of a case where we would need to consider those
characters in an element, and hence suggest that we change all "string"
base types in SPPP to "token". Anybody aware of an element where we
should make an exception from that rule?

(Disclaimer: I'm not a XML expert, though!)

NAPTR
--------

RFC 4114 contains an "IESG-tested" schema definition for the contents of
a NAPTR record. We should probably re-use that, instead of creating a
new definition:

http://tools.ietf.org/html/rfc4114#section-4

Format of Nameservers / IP addresses
-----------------------------------------------

The same applies to the definition of IP addresses and nameserver names,
those could be copied over from the respective EPP specifications in
RFC5731 (and adapted slightly, as needed). The definition for IP
addresses there is:

   <complexType name="addrType">
      <simpleContent>
        <extension base="host:addrStringType">
          <attribute name="ip" type="host:ipType"
           default="v4"/>
        </extension>
      </simpleContent>
    </complexType>

    <simpleType name="addrStringType">
      <restriction base="token">
        <minLength value="3"/>
        <maxLength value="45"/>
      </restriction>
    </simpleType>

    <simpleType name="ipType">
      <restriction base="token">
        <enumeration value="v4"/>
        <enumeration value="v6"/>
      </restriction>
    </simpleType>

Again, this would have the advantage that we use an IESG-approved
definition from an existing RFC.

URIs
------

Note that XML Schema contains a base type for URIs. we could use that
one eg. for tghe definition of the "uri" element in the "URIType":

http://www.w3.org/TR/xmlschema-2/#anyURI

(plus, i'm sure we want that field, like other fields that contain URIs,
limit to absolute URIs, because we don't have a definition what the base
for a relative URI would be - i think that can only be done in text,
though - not in Schema).

(However, given that the "uri" element can contain backreferences, the
base type "URI" would probably not be appropriate, because it's not an
actual URI?)

I hope we can use that information above as a basis to discuss data
validation during the interim meeting - if someone comes up with
different ideas, please share on the list!

Alex

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 30 Aug 2011 11:03:41 -0400

Hi Alex,

Excellent contribution.  I think all of your proposals are reasonable.  We can implement these improvements into the spec in a couple hours, once we get concensus.

My only slight concern is about _requiring_ the "+" sign in TNs.  Not all sequence of digits that will be provisioned into this field are going to be e164 numbers.  So I'd say making the "+" optional would be good.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Monday, August 29, 2011 7:17 AM
To: [email-masked]
Subject: [drinks] on data validation...

<wg chair hat off>

Object Names
------------------

 - dgName
 - rrName
 - egrRteName
 - rgName

Transaction IDs
------------------

 - clientTransId
 - serverTransId

- tn
- rn
- startTN
- endTN
- tnPrefix

Organizations
----------------

NAPTR
--------

URIs
------

Alex

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: <[email-masked]>
Date: Wed, 31 Aug 2011 11:28:21 +0200

Hi Alex,

FWIW on this point, I think what you say is that in some signaling
protocols 
(eg ISUP) parameters originally defined for E.164 numbers are also used 
to convey things like hexadecimal strings even if they're not part of 
the numbering plan. And indeed this is correct, and was also reflected 
in RFC 3966 in the section on such strings along with DTMF (see section 
5.1.3.). (There was a time when these were explicitly ruled out in an
annex 
to the recommendation, now gone). If you use "e164numberType" as
simpleType 
name, my personal inclination therefore would be not to change that
definition 
from RFC5105 to be consistent, and keep "\+\d\d*". 

Non E.164 formats, however, are a valid use case for interconnect
especially 
when you use NP-corrected numbers with a national prefix. It may
therefore 
also make sense to cover these in the schema (which I think it also
relates 
to Ken's observation on the '+' sign). If you want to address that and 
provided that's within charter, I'd suggest you simply change the
simpleType 
name for clarity and allow for a more flexible syntax. 

I hope this helps,
Regards,

Philippe Fouquart
R&D/CORE/NAS
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Mayrhofer
Sent: Monday, August 29, 2011 7:17 AM
To: [email-masked]
Subject: [drinks] on data validation...

<snip>

<snip>