您的位置：首页 > 其它

MRCP v2.0 规范 - RFC6787中文翻译（5）

2019-03-17 12:55 225 查看

MRCPv2通用方法，头和结果内容

  本章讲述MRCPv2支持一组所有资源共有的方法和头字段。资源特定的方法和标题字段在文档的相应资源特定部分中讨论。

6.1 通用方法

MRCPv2支持两种通用方法，用于读取和更新与资源关联的状态。

 

generic-method      =    "SET-PARAMS"

/    "GET-PARAMS"

 

下面详细的介绍两种方法.

 

  1. SET-PARAMS

 

  从客户端到服务端的SET-PARAMS请求可以定义或修改MRCPv2资源会话的参数，例如语音特征和合成器上的韵律，识别器上的识别定时器等。如果服务端接受并设置所有参数，则必须返回200的响应状态代码，如果它选择忽略一些可以安全忽略的可选头字段而不影响服务端的操作，它必须返回201。

 

  如果发送的一个或多个头字段不正确，则必须返回错误403,404或409，如下所示：

 

  • 如果设置的一个或多个头字段具有非法值，则服务端必须返回带有头字段的404非法值的响应。
  • 如果资源不支持所设置的一个或多个头字段，则服务端必须返回带有403 Unsupported Header字段的响应。
  • 如果设置的一个或多个头字段具有不支持的值，则服务端必须返回带有409 Unsupported Header Field Value的响应。

 

  如果同时发生错误404和另一个错误，则只返回错误404，如果错误403和409同时发生，则只返回错误403，如果返回错误403,404或409，则响应必须包括与客户端发送的字段完全相同错误或不支持的头字段及其值。使用修改的会话参数SET-PARAMS不会覆盖在单个请求或IN-PROGRESS请求中明确指定的参数。

 

C->S:  MRCP/2.0 ... SET-PARAMS 543256

Channel-Identifier:32AECB23433802@speechsynth Voice-gender:female

Voice-variant:3

 

S->C:  MRCP/2.0 ... 543256 200 COMPLETE

Channel-Identifier:32AECB23433802@speechsynth

 

  1. GET-PARAMS

 

  从客户端到服务端的GET-PARAMS请求可以向MRCPv2资源询问其当前会话参数，例如语音特征和合成器上的韵律，识别器上的识别定时器等。对于每个头部字段，客户端在请求中发送一个值，服务端必须在响应中包含头字段及其对应的值，如果客户端没有指定参数头字段，则服务端必须返回响应的相应头部分中的所有可设置参数及其值，包括特定于供应商的参数。这种通配符参数请求可能是非常耗费处理的，因为可设置参数的数量可能很大，具体取决于实现。因此，建议客户端不要经常使用通配符GET-PARAMS操作。请注意，GET-PARAMS返回应用于整个会话的头字段值，而不是具有请求级别范围的值。例如，Input-Waveform-URI是请求级头字段，因此GET-PARAMS不会返回内容。

 

  如果支持所有请求的头字段，则服务端必须返回200的响应状态代码。如果检索到的某些头字段不支持该资源，则服务端必须拒绝具有403 Unsupported Header字段的请求。 这样的响应必须包括不受支持的头字段，与客户端发送的字段内容完全相同。

 

C->S:   MRCP/2.0 ... GET-PARAMS 543256

Channel-Identifier:32AECB23433802@speechsynth Voice-gender:

Voice-variant:

Vendor-Specific-Parameters:com.example.param1; com.example.param2

 

S->C:   MRCP/2.0 ... 543256 200 COMPLETE

Channel-Identifier:32AECB23433802@speechsynth Voice-gender:female

Voice-variant:3

Vendor-Specific-Parameters:com.example.param1="Company Name"; com.example.param2="124324234@example.com"

6.2 通用消息头

  所有MRCPv2头字段（包括以下子节中定义的通用头和稍后定义的资源特定头字段）遵循与RFC 5322第3.1节中给出的相同的通用格式,每个标题字段由一个名称后跟一个冒号（’:’）和值组成,标题字段名称不区分大小写值可以在任何数量的LWS（线性空白空间）之前，尽管优选单个SP（空格）。通过在每个额外线之前具有至少一个SP或HT（水平标签），标题字段可以在多行上延伸。

 

generic-field  = field-name ":" [ field-value ] field-name = token

field-value    = *LWS field-content *( CRLF 1*LWS field-content) field-content   = <the OCTETs making up the field-value

and consisting of either *TEXT or combinations of token, separators, and quoted-string>

 

  字段内容不包括任何前导或尾随LWS（在字段值的第一个非空白字符之前或在字段值的最后一个非空白字符之后出现的空白）,可以在不改变字段值的语义的情况下移除这种前导或尾随LWS,在解释字段值或向下游转发消息之前，可以用单个SP替换在字段内容之间发生的任何LWS。

 

  MRCPv2服务端和客户端不得依赖于头字段顺序。建议先发送通用头字段，然后是request-header或response-header字段，最后是entity-header字段。但是，MRCPv2服务端和客户端必须准备好以任何顺序处理头字段。此规则的唯一例外是当消息中有多个具有相同名称的头字段时，具有相同名称的多个头字段可以存在于消息中当且仅当该头字段的整个值被定义为以逗号分隔的列表[#(value)]时。

  由于特定供应商的参数可能依赖于顺序，因此可以将多个相同名称的头字段组合成一个’name:value’对而不改变消息的语义，方法是将每个后续值附加到第一个，每个用逗号分隔。 因此，接收具有相同名称的头字段的顺序对于组合头字段值的解释是重要的，因此中间件在转发消息时不得改变这些值的顺序。

 

     通用头值

=

channel-identifier

 

/

accept

 

/

active-request-id-list

 

/

proxy-sync-id

 

/

accept-charset

 

/

content-type

 

/

content-id

 

/

content-base

 

/

content-encoding

 

/

content-location

 

/

content-length

 

/

fetch-timeout

 

/

cache-control

 

/

logging-tag

 

/

set-cookie

 

/

vendor-specific

 

  1. Channel-Identifier

 

  所有MRCPv2请求，响应和事件必须包含Channel-Identifier头字段。当会话中添加控制信道,并通过SDP应答中的’a=channel’属性传送给客户端时，服务端分配该值。 该字段值由2个部分组成，由’@’符号分隔，第一部分是识别MRCPv2会话的明确字符串。第二部分是字符串标记，它指定3.1节中列出的一种媒体处理资源类型，明确的字符串（第一部分）必须难以猜测，在服务端管理的资源实例中是唯一的，并且对于通过单个SIP对话建立的服务端的所有资源信道是通用的。

 

channel-identifier  = "Channel-Identifier" ":" channel-id CRLF channel-id = 1*alphanum "@" 1*alphanum

 

  1. Accept

 

  Accept头字段遵循[H14.1]中定义的语法,语义也是相同的，但是如果不存在Accept头字段，则服务端必须采用特定资源类型的默认值。通过在SET-PARAMS方法中发送此头字段，可以为会话上的资源更改此默认值,可以通过GET-PARAMS方法找到会话中资源的此头字段的当前默认值，该头字段可以在任何请求上出现。

 

  1. Active-Request-Id-List

 

  此头字段表示请求适用的请求ID列表。当有多个请求处于PENDING或IN-PROGRESS并且客户端希望此请求专门应用于其中一个或多个请求时非常有用。

 

  在响应中，此头字段返回方法修改或影响的请求ID列表。在请求状态PENDING或IN-PROGRESS中可能存在一个或多个请求。当影响一个或多个PENDING或IN-PROGRESS请求的方法从客户端发送到服务端时，响应必须包含在其头部分中受此命令影响或修改的请求ID列表。

  Active-Request-Id-List仅用于请求和响应，而不能用于事件。例如，如果没有Active-Request-Id-List的STOP请求被发送到在PENDING或IN-PROGRESS状态下有一个或多个SPEAK请求的合成器资源，则必须取消所有SPEAK请求，包括一个IN-PROGRESS。对STOP请求的响应在Active-Request-Id-List值中包含已终止的所有SPEAK请求的请求ID，发送STOP响应后，服务端不能为已终止的请求发送任何SPEAK-COMPLETE 或RECOGNITION-COMPLETE事件。

 

active-request-id-list  =  "Active-Request-Id-List" ":"

request-id *("," request-id) CRLF

 

  1. Proxy-Sync-Id

 

  当任何服务端资源生成’barge-in-able’事件时，它还会生成唯一标记，此标记作为此头字段在事件中的值发送给客户端,然后，客户端充当服务端资源中的媒介，并通过收到的Proxy-Sync-Id向合成器服务端资源发送BARGE-IN-OCCURRED方法，当识别器和合成器资源是同一会话的一部分时，他们可以选择一起工作以实现更快的交互和响应。这里，Proxy-Sync-Id帮助接收由客户端中转的事件的资源决定是否已经通过资源的直接交互处理了该事件，此头字段可能仅在事件和BARGE-IN-OCCURRED方法上发生，此头字段的名称仅包含’proxy’一词，仅出于历史原因，它并不表示涉及代理服务端。

 

 proxy-sync-id = "Proxy-Sync-Id" ":" 1*VCHAR CRLF

 

  1. Accept-Charset

 

  见[H14.2],这指定响应中返回的实体或与此请求关联的事件的可接受字符集。这在指定要在RECOGNITION-COMPLETE事件的自然语言语义标记语言（NLSML）结果中使用的字符集时很有用，此头字段仅用于请求。

 

  1. Content-Type

 

  见[H14.17],MRCPv2支持的媒体类型在一定范围内，包括语音标记，语法和识别结果。适用于每个MRCPv2资源类型的内容类型在文档的相应部分中指定，并在IANA维护的MIME

 

媒体类型注册表中注册，支持多媒体内容类型”multipart/mixed”以传达上述内容的多个，在这种情况下，正文部分绝不能包含任何特定于MRCPv2的头部字段，此头字段可能出现在所有消息上。

 

content-type     =    "Content-Type" ":" media-type-value CRLF media-type-value =   type "/" subtype *( ";" parameter )

type             =    token

subtype          =    token

parameter        =    attribute "=" value attribute =   token

value            =    token / quoted-string

 

  1. Content-ID

 

  此头字段包含可通过其引用的内容的ID或名称，该头字段根据RFC 2392 [RFC2392]中的规范操作，并且是多部分消息中的内容消歧所必需的，在MRCPv2中，只要客户端或服务端存储相关内容，就必须使用此ID检索它，通过使用第13.6节中描述的“会话”URI方案对其进行寻址，可以在会话中稍后引用此类内容。 此头字段可能出现在所有消息上。

 

  1. Content-Base

 

  Content-Base实体头可用于指定用于解析实体内相对URI的基URI。

 

content-base      = "Content-Base" ":" absoluteURI CRLF

 

  但是，请注意，实体主体内的内容的基URI可以在该实体主体内重新定义，一个例子是多实体媒体，其中可以有多个实体，此头字段可能出现在所有消息上。

 

  1. Content-Encoding

 

  Content-Encoding实体头用作Content-Type的修饰符。当存在时，其值指示已对实体主体应用了哪些附加内容编码，因此必须应用哪些解码机制以获得由Content-Type头部字段引用的媒体类型，Content-Encoding主要用于允许压缩文档而不会丢失其底层媒体类型的标识，请注意，SIP会话可用于确定已接受的编码（请参阅第7节），此头字段可能出现在所有消息上。

 

content-encoding  = "Content-Encoding" ":"

*WSP content-coding

*(*WSP "," *WSP content-coding *WSP ) CRLF

 

  内容编码在[H3.5]中定义。它的一个使用例子是Content-Encoding：gzip

      如果已实体应用了多个编码模式，则必须按照应用顺序列出内容编码。

 

 

 

  1. Content-Location

 

  当所请求资源的URI和实体资源不在同一个位置时，Content-Location实体头可用于为消息中包含的实体提供资源位置，请参阅[H14.14]。

 

content-location  =  "Content-Location" ":"

( absoluteURI / relativeURI ) CRLF

 

  Content-Location值是在请求时对应于该特定实体的资源的位置的声明，此头字段仅用于优化目的，该头字段的接收者可以假设正在发送的实体与已经检索的实体相同或者可能已经从内容位置URI中检索到的实体。例如，如果客户端提供内联语法标记，并且之前已从某个URI检索到它，则可以使用Content-Location头字段将该URI作为实体的一部分提供，这允许像识别器这样的资源查看其缓存，以查看此语法是否先前已被检索，编译和缓存，在这种情况下，它可以通过使用先前编译的语法对象进行优化。如果Content-Location是相对URI，则相对URI将相对于Content-Base URI进行解释。 此头字段可能出现在所有消息上。

 

  1. Content-Length

 

  该头字段包含消息体内容的长度（在最后一个头字段之后的双CRLF之后）。与HTTP不同，它必须包含在头字段部分之外的内容的所有消息中，如果缺少，则假定默认值为零，否则，根据[H14.13]中说明，当没有用于包含了无用的消息体时，即Content-Length不为零时，接收方必须忽略消息体的内容，此头字段可能出现在所有消息上。

 

content-length  =  "Content-Length" ":" 1*19DIGIT CRLF

 

  1. Fetch Timeout

 

  当识别器或合成器需要获取文档或其他资源时，此头字段控制相应的URI访问属性。这定义了服务端通过网络获取内容可能超时时间，该值被解释为以毫秒为单位，范围从0到特定于实现的最大值，建议服务端对接受长超时值持谨慎态度，此头字段的默认值是特定于实现的，该头字段可以出现在DEFINE-GRAMMAR，RECOGNIZE，SPEAK，SET-PARAMS或GET-PARAMS中。

 

fetch-timeout =  "Fetch-Timeout" ":" 1*19DIGIT CRLF

 

 

  1. Cache-Control

 

  如果服务端实现内容缓存，则在访问和缓存存储的内容时，必须遵守HTTP 1.1 [RFC2616]的缓存正确性规则。特别是，缓存的URI或文档的“expires”和“cache-control”头字段必须遵守，并优先于此头字段设置的Cache-Control默认值，Cache-Control指令用于在服务端上为会话或请求定义默认缓存算法，该指令的范围基于它发送的方法，如果指令是在SET-PARAMS方法上发送的，则它适用于服务端在该会话期间对外部文档的所有请求，除非它被单个请求上的Cache-Control头字段覆盖，如果指令是在任何其他请求上发送的，则它们仅适用于服务端为该请求发出的外部文档请求，GET-PARAMS方法上的空Cache-Control头字段是服务端返回服务端上当前Cache-Control指令设置的请求，此头字段在请求时发生。

 

cache-control    =    "Cache-Control" ":"

[*WSP cache-directive

*( *WSP "," *WSP cache-directive *WSP )] CRLF

 

cache-directive     = "max-age" "=" delta-seconds

/ "max-stale" [ "=" delta-seconds ]

/ "min-fresh" "=" delta-seconds

 

delta-seconds       = 1*19DIGIT

 

这里，delta-seconds是一个十进制时间值，指定自服务端接收消息响应或数据以来的秒数。

不同的cache-directive选项定义了客户端要求服务端覆盖默认的缓存过期机制：

max-age        表示客户端可以使用缓存数据最大时间（不大于指定时间（秒）的内容）， 除非使用’max-stale’指令，否则客户端不会继续使用缓存。

 

min-fresh      表示客户端愿意接受具有缓存数据的服务端响应，缓存数据的到期时间不小于其当前时间加上指定的时间（以秒为单位）。如果服务端的缓存生存时间超过客户端提供的最小值，则服务端不得使用缓存内容。

 

max-stale      表示客户端愿意允许服务端使用超过其到期时间的缓存数据，如果为’max-stale’分配了值，则客户端愿意允许服务端使用超过其到期时间的缓存数据不超过指定的秒数。如果没有为’max-stale’分配值，则客户端愿意允许服务端使用任何过期的缓存数据。

 

 

  如果请求服务端缓存在没有验证的情况下使用过时的响应/数据，只能在不与任何有关缓存验证的”必须”级别要求相冲突的情况下才可以这样做（例如，“必须重新验证”的Cache-Control指令 与相应URI相关的HTTP 1.1规范）.

 

  如果MRCPv2 Cache-Control指令和服务端上的高速缓存条目都包含’max-age’指令，则这两个值中较小的一个用于确定该请求的高速缓存条目的过去时间。

 

  1. Logging-Tag

 

  该头字段可以作为SET-PARAMS/GET-PARAMS方法的一部分发送，以设置或检索服务端的日志标记。设置后，该值将持续存在，直到设置新值或会话结束。MRCPv2服务端可以提供一种机制来创建其输出日志的子集，以便系统管理员可以检查或仅提取日志文件部分，在此期间日志标记设置为特定值。

 

  建议客户端在日志标记信息中包含标识MRCPv2客户端用户代理的信息，以便可以确定哪个MRCPv2客户端请求在服务端上生成给定的日志消息，同时建议MRCPv2客户端不记录个人身份信息，如信用卡号码和身份证号码等敏感信息。

 

  logging-tag = "Logging-Tag" ":" 1*UTFCHAR CRLF

 

  1. Set-Cookie

 

  由于MRCPv2服务端上的内置HTTP客户端可以代替MRCPv2客户端提取文档以进行处理，因此MRCPv2服务端的HTTP客户端中的cookie存储被视为MRCPv2客户端的HTTP客户端中cookie存储的扩展，这要求MRCPv2客户端和服务端能够根据需要同步其公共cookie存储， 为了使MRCPv2客户端能够将其存储的cookie推送到MRCPv2服务端并从MRCPv2服务端获取存储回MRCPv2客户端的新cookie，可以在MRCPv2请求中包含Set-Cookie实体头字段以更新cookie存储服务端并在最终的MRCPv2响应或事件中返回，以便更新客户端自己的cookie存储。服务端上存储的cookie在MRCPv2会话期间持续存在，并且必须在会话结束时销毁。 为了确保对cookie的支持，MRCPv2客户端和服务端必须支持Set-Cookie实体头字段。请注意，MRCPv2客户端确定将哪些cookie（如果有）发送到服务端。不要求共享所有cookie。相反，建议MRCPv2客户端仅传送MRCPv2服务端处理其请求所需的cookie。

 

set-cookie

cookies cookie cookie-av

=

=

=

=

"Set-Cookie:" cookies CRLF

cookie *("," *LWS cookie)

attribute "=" value *(";" cookie-av) "Comment" "=" value

 

/

"Domain" "=" value

 

/

"Max-Age" "=" value

 

/

"Path" "=" value

 

/

"Secure"

 

/

"Version" "=" 1*19DIGIT

 

/

"Age" "=" delta-seconds

 

set-cookie        = "Set-Cookie:" SP set-cookie-string set-cookie-string = cookie-pair *( ";" SP cookie-av ) cookie-pair   = cookie-name "=" cookie-value cookie-name    = token

cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-octet   = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E token   = <token, defined in [RFC2616], Section 2.2>

cookie-av         = expires-av / max-age-av / domain-av /

path-av / secure-av / httponly-av / extension-av / age-av

expires-av        = "Expires=" sane-cookie-date

sane-cookie-date  = <rfc1123-date, defined in [RFC2616], Section 3.3.1> max-age-av = "Max-Age=" non-zero-digit *DIGIT

non-zero-digit    = %x31-39

domain-av         = "Domain=" domain-value domain-value   = <subdomain>

path-av           = "Path=" path-value

path-value        = <any CHAR except CTLs or ";"> secure-av  = "Secure"

httponly-av       = "HttpOnly"

extension-av      = <any CHAR except CTLs or ";"> age-av  = "Age=" delta-seconds

 

  Set-Cookie头字段在RFC 6265 [RFC6265]中指定。’规范’属性在本规范中引入，用于指示cookie的年龄并且是可选的。MRCPv2客户端或服务端必须根据HTTP/1.1规范[RFC2616]中的年龄计算规则计算cookie的年龄，并相应地附加’Age’属性。提供此属性是因为客户端从HTTP服务端收到cookie后可能已经过了一段时间。它不是让客户端按实际年龄减少Max-Age，而是逐字传递Max-Age并附加’Age’属性，从而保持cookie的接收状态，同时仍然考虑到时间已经过去的事实。

  如果HTTP源服务端省略它们，MRCPv2客户端或服务端必须提供RFC 6265中指定的“域”和“路径”属性的默认值。请注意，在这种情况下，“域”属性值中不存在前导点。虽然可以修改通过HTTP协议接收的明确指定的“域”值以包括前导点，但是当通过MRCPv2协议接收时，MRCPv2客户端或服务端不得修改“域”值。

 

  MRCPv2客户端或服务端可以将相同类型的多个cookie头字段组合成单个“字段名:字段-值”对，如第6.2节所述。

 

  可以在随后导致服务端执行HTTP访问的任何请求中指定Set-Cookie头字段。当服务端从HTTP源服务端接收新的cookie信息，并假设根据RFC 6265修改cookie存储时，服务端必须在MRCPv2 COMPLETE响应或事件中返回新的cookie信息（如果适用），以允许客户端更新它自己的cookie存储。

 

  SET-PARAMS请求可以指定Set-Cookie头字段来更新服务端上的cookie存储。GET-PARAMS请求可用于将”Set-Cookie”类型cookie的整个cookie存储返回给客户端。

 

 

 

  1. Vendor-Specific Parameters

 

 这组头字段允许客户端设置或获取服务商特定的参数。

 

      vendor-specific =  "Vendor-Specific-Parameters" :

[vendor-specific-av-pair

*(";" vendor-specific-av-pair)] CRLF

 

      vendor-specific-av-pair = vendor-av-pair-name "="

value         vendor-av-pair-name = 1*UTFCHAR

  此表单的头字段可以以任何方法（请求）发送，并用于管理服务端的特定参数的实现。 vendor-av-pair-name遵循反向Internet域名约定（有关语法和注册信息，请参见第13.1.6节），vendor属性的值在’=’符号后面指定，并且可以引用。例如：

 

com.example.companyA.paramxyz=256 com.example.companyA.paramabc=High com.example.companyB.paramxyz=Low

 

  当使用GET-PARAMS中从服务端获取这些参数的当前值时，此头字段值可以包含以分号分隔的特定实现的属性名称列表。

 

6.3 通用结果内容

  来自服务端的识别和验证资源的结果都是在MRCPv2事件消息体中的消息实体来携带的。自然语言语义标记语言（NLSML）是基于W3C早期草案的XML标记，是将结果返回给客户端的默认标准。因此，实现这些资源类型的所有服务端必须支持媒体类型'application/nlsml + xml'。可扩展多模注释（EMMA）[W3C.REC-emma-20090210]格式也可用于返回结果。这可以通过在会话建立时与SDP（a=resultformat：application/emma+xml）或SIP（Allow/Accept）协商格式来完成。 例如，如果客户需要结果在EMMA中，MRCPv2服务端可以通过检查SIP头字段将请求路由到另一个支持EMMA的服务端，而不必检查SDP。

 

  MRCPv2使用如下消息格式在客户端和服务端之间传达内容，MRCPv2专门使用NSLML在MRCPv2服务端和客户端之间传递识别，注册和验证结果。第6.3.1节详细描述了此结果格式。

 

Content-Type:application/nlsml+xml Content-Length:...

 

<?xml version="1.0"?>

<result xmlns="urn:ietf:params:xml:ns:mrcpv2" xmlns:ex="http://www.example.com/example" grammar="http://theYesNoGrammar">

<interpretation>

<instance>

<ex:response>yes</ex:response>

</instance>

<input>OK</input>

</interpretation>

</result>

 

结果例子

 

6.3.1 自然语言语义标记语言

 

  自然语言语义标记语言(Natural Language Semantics Markup Language NLSML) 是一种XML数据结构，其元素和属性旨在承载来自识别器、注册和验证者资源的结果信息。NLSML的规范定义是第16.1节中的RelaxNG模式。请注意，此格式的元素和属性在MRCPv2名称空间中定义。在结果内容结构中，它们必须以结果中声明的名称空间前缀作为前缀，或者是标记为属于相应名称空间的元素的子项，有关如何使用XML命名空间的详细信息，请参阅[W3C.REC-xml-names11-20040204]，[W3C.REC-xml-names11-20040204]的第2节提供了有关如何声明名称空间和名称空间前缀的详细信息。

 

  NLSML的根元素是<result>，可选的子元素是<interpretation>、<enrollment-result>、<verification-result>，其中至少有一个元素必须存在，单个<result>可以包含一个或多个子元素，有关<result>和<interpret>元素及其子元素和属性的详细信息，请参见第9.6节，有关<enrollment-result>元素及其子元素的详细信息，请参见第9.7节，有关<verification-result>元素及其子元素的详细信息，请参见第11.5.2节。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签： 
相关文章推荐
新的分享
章节导航