We've recently moved hosts! Please report any weirdness with the wiki (or spam) on Utopia.

NuDOC Protocol RFC/List of server responses

From BBSWiki

Jump to: navigation, search

Server messages always contain a ControlMessage, which is currently one of RDY (only presented on login prompt), ACK (last message from client acknowledged) or NAK (last message from client not acknowledged). This message can be used by lightweight clients to evaluate the server's response to requests. The messages also contain a numeric ControlCode. i18n clients can use this to figure out a message or error message to display. See NuDOC Protocol RFC/List of Control Codes.

Contents

[edit] Login, logout and account creation

[edit] LoginPrompt

This is a "response" to the client's final ACK in the handshake. Contains the login splash screen, limited to 1920 characters (24x80).

<LoginPrompt>
  <ControlSegment>
    <ControlMessage>RDY</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <BBSName>...</BBSName>
  <LoginSplash>
  ...
  </LoginSplash>
</LoginPrompt>

[edit] LoginResponse

ACK or NAK the username/password offered by the client. If ACK, include some data and statistics. The LoginResponseData section is absent with a NAK.

<LoginResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <LoginResponseData>
    <LastLoginTimestamp>...</LastLoginTimestamp>
    <LastLogoutTimestamp>...</LastLogoutTimestamp>
    <LastHost>...</LastHost>
    <CallNum>...</CallNum>
    <NumUsers>...</NumUsers>
    <eXpressState>...</eXpressState>
    <GuideState>...</GuideState>
  </LoginResponseData>
</LoginResponse>

[edit] LogoutResponse

ACK and close connection.

<LogoutResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
</LogoutResponse>

[edit] NewUserCheckResponse

ACK if name available.

AccountCreationAllowed specifies whether the account can be created on this connection. It could be set to no by the sysops.

<NewUserCheckResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <NewUserCheckData>
    <AccountCreationAllowed>true</AccountCreationAllowed>
    <AccountCreationPasswordProtected>true</AccountCreationPasswordProtected>
    <MandatoryField>...</MandatoryField>
    <MandatoryField>...</MandatoryField>
  </NewUserCheckData>
</NewUserCheckResponse>

[edit] NewUserPasswordCheckResponse

ACK on password okay. NAK on wrong password.

<NewUserPasswordCheckResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
</NewUserPasswordCheckResponse>

[edit] NewUserCreateResponse

ACK if account created, NAK if failure.

<NewUserCreateResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
</NewUserCreateResponse>

[edit] User functions

[edit] UserHideProfileFieldsResponse

<UserHideProfileFieldsResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
</UserHideProfileFieldsResponse>

[edit] UserChangeProfileTextResponse

ACK for anything that's not too long.

<UserChangeProfileTextResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
</UserChangeProfileTextResponse>

[edit] UserProfileResponse

ACK if extant user and user can profile (not guest, twit, etc).. NAK on bad user or no permission. Lacks any hidden fields. See NuDOC Protocol RFC/Complex data types#User

<UserProfileResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <User>
  ...
  </User>
</UserProfileResponse>

[edit] UserStatusResponse

ACK if extant user and user can profile (not guest, twit, etc).. NAK on bad user or no permission. Returns user online/offline status and guide/op/Xdisable status etc.

<UserStatusResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <User>
  ...
  </User>
</UserStatusResponse>

[edit] Room functions

[edit] RoomDetailsResponse

ACK for extant room, NAK for non-extant or "hidden" room. Doesn't return roominfo-related stuff.

<RoomDetailsResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <Room>
    <RoomNumber>...</RoomNumber>
    <RoomName>...</RoomName>
    <LastMessage>...</LastMessage>
    <FirstMessageUnread>...</FirstMessageUnread>
    <RoomAide>...</RoomAide>
    <RoomAide>...</RoomAide>
  </Room>
</RoomDetailsResponse>

[edit] Message functions

[edit] MessageHeadersInRangeResponse

ACK for range with any valid messages, NAK for invalid range (for example, room message number ends at 1200 and range request is 1250-1300). No delivery order guaranteed. Client should sort.

<MessageHeadersInRangeResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <MessageHeader>
  ...
  </MessageHeader>
  <MessageHeader>
  ...
  </MessageHeader> 
</MessageHeadersInRangeResponse>

[edit] MessageBodyByGlobalResponse

ACK for message successfully retrieved. NAK for nonexistent message or one which user is not allowed to read. See MessageBody complex data type.

<MessageBodyByGlobalResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <MessageBody>
  ...
  </MessageBody>
</MessageBodyByGlobalResponse>

[edit] PostMessageResponse

ACK if post was successful, NAK for any type of a problem. Returns the global message number of the post on success.

<PostMessageResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <GlobalMessageNumber>...</GlobalMessageNumber>
</PostMessageResponse>

[edit] eXpress and Wholist functions

[edit] WholistResponse

Contains UserNumber, Username, City, StateProvince, ConnectFrom, DoingField, and any StatusFlags for each logged in user. Hidden fields will be omitted. Not in any order. Client should sort. See NuDOC Protocol RFC/Complex data types#User.

<WholistResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
  <Wholist>
    <User>
    ...
    </User>
    <User>
    ...
    </User>
  </Wholist>
</WholistReponse>

[edit] SendeXpressResponse

ACK if eXpress received for sure. NAK on any problem.

<SendeXpressResponse>
  <ControlSegment>
    <ControlMessage>ACK</ControlMessage>
    <ControlCode>...</ControlCode>
  </ControlSegment>
</SendeXpressResponse>
Personal tools