Subject: [drinks] Updates to the protocol document...

From: "Ali, Syed Wasim" <[email-masked]>
Date: Wed, 26 Jan 2011 12:18:16 -0500

Hi,

Manjul thanks for reviewing the protocol document and pointing out areas
that require fixes or updates in the email back on Nov 29. The following
list of comments have been addressed.

  -S-Sect 6.11, page 47: third line  typo, should be ³serve² instead of
³server².

  -S-Sect 7.1, page 55: Mismatch in clientTransId values between the query
and response.

  -S-Sect 7.3, page 57: Namespace usage for the elements is shown
inconsistently  it is not shown for rantId and rarId, but is shown for
rrName, ete and uri.

  -S-Sect 7.6, page 61: ³rantId0² and ³rarId0² should be replaced with
³iana-en:222².

  -S-Sect 7.16, page 72: Same example  should be ³iana-en:111² instead of
³ssp1².
  -S-Sect 7.17, page 72: Typo in heading  should be ³Egress².

  -S-Sect 8.1, page 79: Typo  should be ³the² instead of ³te².

  -S-Sect 7.5, page 60: CorDateTime is shown as prior to the Creation date
time. Is this an oversight, or there is additional implication behind this
 ie the Registry can return back the Date Time when the Regulatory body
actually affirmed the COR claim of the Registrant? IMO, that imposes
unnecessary requirement on the Registry and so the COR date time should be
at or after the Creation date time.
=======[SYED] The date in XML message has been fixed

  -S-Sect 6.9, page 41: Layout and description of the attributes in TNType
(such as corInfo) is inconsistent with the way it is defined in other
places. Rest of the doc has the XSD definition first, and then the
explanation of the parameters/attributes. Accordingly, this definition
should go after the XSD specification on top of page 42.

  -S-Sect 7.6, page 61: IMO, the rn parameter should be in E.164 format.
Having said that, we haven¹t made any statement in the doc wrt E.164
nature of the TN/TNR/TNP/RN parameters  the question is should we? I
think it should be left to the local policy of the Registry on how to
handle non-E.164 elements being provisioned (e.g.: use some other rules to
determine how to normalize such data prior to storage and/or further
distribution). However, that does add avoidable complications, and it
might be preferable to simply store everything as E.164 objects.
====[SYED] We discussed this aspect in the last design team meeting and I
think the general consensus is to let the local policy exercise the
Registry preferences.

-Syed